1) Do you agree about using “associatedtype”?
2) If not, which keyword would you prefer to use? why? (you can introduce
a new one)
There is another alternative. Rather than trying to come up with another
brand-new keyword, we can re-use one that has an existing and appropriate
meaning: required.
It's a little more verbose at the point of use but the declarations are
relatively uncommon and this usage is clearly separate from regular
typealias declarations.
I think this is a big improvement over associatedtype, except that the type that satisfies the requirement needn't be a typealias. I would therefore prefer "requiredtype."
-Dave
···
On Dec 19, 2015, at 12:17 PM, Michael Henson via swift-evolution <swift-evolution@swift.org> wrote:
1) Do you agree about using “associatedtype”?
2) If not, which keyword would you prefer to use? why? (you can introduce a new one)
There is another alternative. Rather than trying to come up with another brand-new keyword, we can re-use one that has an existing and appropriate meaning: required.
It's a little more verbose at the point of use but the declarations are relatively uncommon and this usage is clearly separate from regular typealias declarations.
1) Do you agree about using “associatedtype”?
2) If not, which keyword would you prefer to use? why? (you can introduce a new one)
There is another alternative. Rather than trying to come up with another brand-new keyword, we can re-use one that has an existing and appropriate meaning: required.
It's a little more verbose at the point of use but the declarations are relatively uncommon and this usage is clearly separate from regular typealias declarations.
I don't link this as it's not entirely accurate. Associated types are somewhat different than typealiases and are often inferred, not declared in the conforming types.
···
Sent from my iPhone
On Dec 19, 2015, at 2:17 PM, Michael Henson via swift-evolution <swift-evolution@swift.org> wrote:
There is another alternative. Rather than trying to come up with another brand-new keyword, we can re-use one that has an existing and appropriate meaning: required.
It's a little more verbose at the point of use but the declarations are relatively uncommon and this usage is clearly separate from regular typealias declarations.
I don't think `required` captures the intended meaning *at all*. You're not required to declare the type of a "required typealias"—it's often, perhaps even usually, inferred. On the other hand, all types conforming to ExampleProtocol are "required" in some sense to have an Element, but they're also "required" to have a MethodSignature. (In fact, they're required to have exactly the MethodSignature specified there, but they can have any Element they want.) It's just not a good match.
If you wanted to analogize associated types to some existing feature, it would clearly be generics (but this is not done for very good reasons). If you wanted to reuse an existing keyword at all costs, I suspect what you should actually do is mark the non-associated type with `final` (but this doesn't match typealiases in other types, and it doesn't solve the searchability problem with using "typealias" for associated types).
The whole reason we got into this mess is because we unwisely reused a keyword for something barely related. Let's not do it again.
Step Christopher
Big Nerd Ranch, LLC
schristopher@bignerdranch.com
···
On Sat, Dec 19, 2015 at 3:54 PM, Dave Abrahams via swift-evolution < swift-evolution@swift.org> wrote:
On Dec 19, 2015, at 12:17 PM, Michael Henson via swift-evolution < > swift-evolution@swift.org> wrote:
1) Do you agree about using “associatedtype”?
2) If not, which keyword would you prefer to use? why? (you can introduce
a new one)
There is another alternative. Rather than trying to come up with another
brand-new keyword, we can re-use one that has an existing and appropriate
meaning: required.
It's a little more verbose at the point of use but the declarations are
relatively uncommon and this usage is clearly separate from regular
typealias declarations.
I think this is a big improvement over associatedtype, except that the
type that satisfies the requirement needn't be a typealias. I would
therefore prefer "requiredtype."
There is another alternative. Rather than trying to come up with another brand-new keyword, we can re-use one that has an existing and appropriate meaning: required.
It's a little more verbose at the point of use but the declarations are relatively uncommon and this usage is clearly separate from regular typealias declarations.
I don't think `required` captures the intended meaning *at all*. You're not required to declare the type of a "required typealias"—it's often, perhaps even usually, inferred.
No, but it is required to exist and can't always be inferred. It puts a constraint on the type that is declared to conform. This is a requirement in exactly the same sense that other protocol requirements are requirements. Notably operator requirements may be satisfied "implicitly" by declarations that already exist, but they are still requirements.
On the other hand, all types conforming to ExampleProtocol are "required" in some sense to have an Element, but they're also "required" to have a MethodSignature. (In fact, they're required to have exactly the MethodSignature specified there, but they can have any Element they want.)
No, that is not a protocol requirement; it doesn't put a constraint on any type that is declared to conform.
It's just not a good match.
If you wanted to analogize associated types to some existing feature, it would clearly be generics (but this is not done for very good reasons). If you wanted to reuse an existing keyword at all costs, I suspect what you should actually do is mark the non-associated type with `final` (but this doesn't match typealiases in other types, and it doesn't solve the searchability problem with using "typealias" for associated types).
The whole reason we got into this mess is because we unwisely reused a keyword for something barely related. Let's not do it again.
I think reusing "required" here (where "typealias" has already been reused) could make the concept of associated types more opaque to new users.
The use of "typealias" as a kind of "typedef" immediately made sense to me. When I first stumbled upon "typealias" in a protocol, it took me some time to fully grok its use and its connection to its "typedef" counterpart.
Stephen
···
On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:
I don't think `required` captures the intended meaning *at all*. You're not required to declare the type of a "required typealias"—it's often, perhaps even usually, inferred.
No, but it is required to exist and can't always be inferred. It puts a constraint on the type that is declared to conform. This is a requirement in exactly the same sense that other protocol requirements are requirements. Notably operator requirements may be satisfied "implicitly" by declarations that already exist, but they are still requirements.
I agree. There are a couple of potentially confusing issues here:
- In principle, all of the declarations in the protocol are “requirements” that a type needs to fulfill to conform to the protocol.
- Except for optional requirements in @objc protocols.
- Except for requirements with default implementations (which currently cannot be written inline in the protocol, but should be allowed some day). Today’s typealiases can have "default implementations” as well.
-Chris
···
On Dec 20, 2015, at 8:27 AM, Stephen Celis via swift-evolution <swift-evolution@swift.org> wrote:
On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
I don't think `required` captures the intended meaning *at all*. You're not required to declare the type of a "required typealias"—it's often, perhaps even usually, inferred.
No, but it is required to exist and can't always be inferred. It puts a constraint on the type that is declared to conform. This is a requirement in exactly the same sense that other protocol requirements are requirements. Notably operator requirements may be satisfied "implicitly" by declarations that already exist, but they are still requirements.
I think reusing "required" here (where "typealias" has already been reused) could make the concept of associated types more opaque to new users.
Given that the type will/must be defined, implicitly or explicitly, by the
adopter of a protocol, what about "adopterType"?
Mike
···
On Mon, Dec 21, 2015 at 11:33 AM, Chris Lattner <clattner@apple.com> wrote:
On Dec 20, 2015, at 8:27 AM, Stephen Celis via swift-evolution < > swift-evolution@swift.org> wrote:
On Dec 19, 2015, at 11:14 PM, Dave Abrahams via swift-evolution < > swift-evolution@swift.org> wrote:
On Dec 19, 2015, at 5:09 PM, Brent Royal-Gordon via swift-evolution < > swift-evolution@swift.org> wrote:
I don't think `required` captures the intended meaning *at all*. You're
not required to declare the type of a "required typealias"—it's often,
perhaps even usually, inferred.
No, but it is required to exist and can't always be inferred. It puts a
constraint on the type that is declared to conform. This is a requirement
in exactly the same sense that other protocol requirements are
requirements. Notably operator requirements may be satisfied "implicitly"
by declarations that already exist, but they are still requirements.
I think reusing "required" here (where "typealias" has already been
reused) could make the concept of associated types more opaque to new users.
I agree. There are a couple of potentially confusing issues here:
- In principle, all of the declarations in the protocol are “requirements”
that a type needs to fulfill to conform to the protocol.
- Except for optional requirements in @objc protocols.
- Except for requirements with default implementations (which currently
cannot be written inline in the protocol, but should be allowed some day).
Today’s typealiases can have "default implementations” as well.