[Accepted] SE-0011 Replace `typealias` keyword with `associatedtype` for associated type declarations


(Douglas Gregor) #1

The review of SE-0011 "Replace `typealias` keyword with `associatedtype` for associated type declarations" ran from January 3-6, 2016. The proposal has been accepted. We will introduce the “associatedtype” syntax in Swift 2.2 (deprecating “typealias”) and remove the “typealias” syntax in Swift 3.

  https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

Thank you to everyone who participated in the review process! We welcome an implementation of this proposal, which is tracked by

  https://bugs.swift.org/browse/SR-511

  - Doug


(Lily Ballard) #2

In the previous thread on this topic, there was a lot of bikeshedding
about the specific keyword. A bunch of people (myself included)
suggested just "associated" instead, some people suggested a few
alternatives (like "type" or "associated type"). I don't recall if
anyone actually explicitly said they prefer the given name
"associatedtype", though there were of course people who voted +1
without opining on the subject at all.

In any case, my point is, given that this proposal is now accepted, are
we committed to the keyword "associatedtype" or is there still room to
pick a different keyword? Enough people in the thread were in favor of
using a different keyword that it seems worth considering.

-Kevin Ballard

···

On Sat, Jan 9, 2016, at 03:18 PM, Douglas Gregor wrote:

The review of SE-0011 "Replace `typealias` keyword with
`associatedtype` for associated type declarations" ran from January
3-6, 2016. The proposal has been *accepted*. We will introduce the
“associatedtype” syntax in Swift 2.2 (deprecating “typealias”) and
remove the “typealias” syntax in Swift 3.

https://github.com/apple/swift-evolution/blob/master/proposals/0011-replace-typealias-associated.md

Thank you to everyone who participated in the review process! We
welcome an implementation of this proposal, which is tracked by

https://bugs.swift.org/browse/SR-511

- Doug

_________________________________________________
swift-evolution-announce mailing list swift-evolution-
announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce


(Chris Lattner) #3

Yes, associatedtype is what we’re planning to go with. We discussed the keyword used carefully, and there was a lot of discussion/bikeshedding about the keyword on the mailing lists.

Here are a few things I remember from the discussion and the core team perspective, but this is definitely not exhaustive of all the discuss.

“type": Overly general, implies a declaration kind that could be used in other places in the language. Associated types are a very specific kind of type, not a general type.

“associated”: Ok on the face of it, but problematic because declarations should be nouns and it isn’t “googlable”.

“associatedtype”: “googlable”. verbose, but specific. Reasonably advanced feature that occurs infrequently, so verbosity is a good thing.

The major argument against associatedtype was that *all* protocol requirements are associated, and we don’t require associatedvar etc. On the balance with other tradeoffs, we felt that this is the right way to go.

On it being a conjoined word, we agreed that the language is currently inconsistent (we have typealias, fallthrough, but also didSet/willSet and @warn_unused_result) and that we should clean it up. Conjoined feels like the right direction to go for this case. We didn’t discuss it but IMO, didSet should get lowercased as well.

-Chris

···

On Jan 9, 2016, at 3:24 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:

In the previous thread on this topic, there was a lot of bikeshedding about the specific keyword. A bunch of people (myself included) suggested just "associated" instead, some people suggested a few alternatives (like "type" or "associated type"). I don't recall if anyone actually explicitly said they prefer the given name "associatedtype", though there were of course people who voted +1 without opining on the subject at all.

In any case, my point is, given that this proposal is now accepted, are we committed to the keyword "associatedtype" or is there still room to pick a different keyword? Enough people in the thread were in favor of using a different keyword that it seems worth considering.


(Chris Lattner) #4

The meta-problem with associated is this:

protocol Foo {
  associated Bar
}

because it is so general and not googlable (and also an advanced feature that all swift users aren’t expected to memorize) it is difficult to find out what is going on here.

-Chris

···

On Jan 9, 2016, at 5:16 PM, Chris Lattner via swift-evolution <swift-evolution@swift.org> wrote:

On Jan 9, 2016, at 3:24 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:

In the previous thread on this topic, there was a lot of bikeshedding about the specific keyword. A bunch of people (myself included) suggested just "associated" instead, some people suggested a few alternatives (like "type" or "associated type"). I don't recall if anyone actually explicitly said they prefer the given name "associatedtype", though there were of course people who voted +1 without opining on the subject at all.

In any case, my point is, given that this proposal is now accepted, are we committed to the keyword "associatedtype" or is there still room to pick a different keyword? Enough people in the thread were in favor of using a different keyword that it seems worth considering.

Yes, associatedtype is what we’re planning to go with. We discussed the keyword used carefully, and there was a lot of discussion/bikeshedding about the keyword on the mailing lists.

Here are a few things I remember from the discussion and the core team perspective, but this is definitely not exhaustive of all the discuss.

“type": Overly general, implies a declaration kind that could be used in other places in the language. Associated types are a very specific kind of type, not a general type.

“associated”: Ok on the face of it, but problematic because declarations should be nouns and it isn’t “googlable”.


(Lily Ballard) #5

That's a fair answer.

Based on this experience, in the future when a proposal is accepted, if there was any serious bikeshedding about the names used in the proposal (in particular, bikeshedding in the actual review thread), it might be a good idea to acknowledge this in the acceptance email and explain both what the final decision is about the name in question as well as a brief explanation as to why.

-Kevin Ballard

···

On Sat, Jan 9, 2016, at 05:16 PM, Chris Lattner wrote:

> On Jan 9, 2016, at 3:24 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:
>
> In the previous thread on this topic, there was a lot of bikeshedding about the specific keyword. A bunch of people (myself included) suggested just "associated" instead, some people suggested a few alternatives (like "type" or "associated type"). I don't recall if anyone actually explicitly said they prefer the given name "associatedtype", though there were of course people who voted +1 without opining on the subject at all.
>
> In any case, my point is, given that this proposal is now accepted, are we committed to the keyword "associatedtype" or is there still room to pick a different keyword? Enough people in the thread were in favor of using a different keyword that it seems worth considering.

Yes, associatedtype is what we’re planning to go with. We discussed the keyword used carefully, and there was a lot of discussion/bikeshedding about the keyword on the mailing lists.

Here are a few things I remember from the discussion and the core team perspective, but this is definitely not exhaustive of all the discuss.

“type": Overly general, implies a declaration kind that could be used in other places in the language. Associated types are a very specific kind of type, not a general type.

“associated”: Ok on the face of it, but problematic because declarations should be nouns and it isn’t “googlable”.

“associatedtype”: “googlable”. verbose, but specific. Reasonably advanced feature that occurs infrequently, so verbosity is a good thing.

The major argument against associatedtype was that *all* protocol requirements are associated, and we don’t require associatedvar etc. On the balance with other tradeoffs, we felt that this is the right way to go.

On it being a conjoined word, we agreed that the language is currently inconsistent (we have typealias, fallthrough, but also didSet/willSet and @warn_unused_result) and that we should clean it up. Conjoined feels like the right direction to go for this case. We didn’t discuss it but IMO, didSet should get lowercased as well.

-Chris


(Douglas Gregor) #6

That's a fair answer.

Based on this experience, in the future when a proposal is accepted, if there was any serious bikeshedding about the names used in the proposal (in particular, bikeshedding in the actual review thread), it might be a good idea to acknowledge this in the acceptance email and explain both what the final decision is about the name in question as well as a brief explanation as to why.

Yes, I should have reported on our rationale.

  - Doug

···

Sent from my iPhone

On Jan 9, 2016, at 5:33 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:

-Kevin Ballard

On Sat, Jan 9, 2016, at 05:16 PM, Chris Lattner wrote:

On Jan 9, 2016, at 3:24 PM, Kevin Ballard via swift-evolution <swift-evolution@swift.org> wrote:

In the previous thread on this topic, there was a lot of bikeshedding about the specific keyword. A bunch of people (myself included) suggested just "associated" instead, some people suggested a few alternatives (like "type" or "associated type"). I don't recall if anyone actually explicitly said they prefer the given name "associatedtype", though there were of course people who voted +1 without opining on the subject at all.

In any case, my point is, given that this proposal is now accepted, are we committed to the keyword "associatedtype" or is there still room to pick a different keyword? Enough people in the thread were in favor of using a different keyword that it seems worth considering.

Yes, associatedtype is what we’re planning to go with. We discussed the keyword used carefully, and there was a lot of discussion/bikeshedding about the keyword on the mailing lists.

Here are a few things I remember from the discussion and the core team perspective, but this is definitely not exhaustive of all the discuss.

“type": Overly general, implies a declaration kind that could be used in other places in the language. Associated types are a very specific kind of type, not a general type.

“associated”: Ok on the face of it, but problematic because declarations should be nouns and it isn’t “googlable”.

“associatedtype”: “googlable”. verbose, but specific. Reasonably advanced feature that occurs infrequently, so verbosity is a good thing.

The major argument against associatedtype was that *all* protocol requirements are associated, and we don’t require associatedvar etc. On the balance with other tradeoffs, we felt that this is the right way to go.

On it being a conjoined word, we agreed that the language is currently inconsistent (we have typealias, fallthrough, but also didSet/willSet and @warn_unused_result) and that we should clean it up. Conjoined feels like the right direction to go for this case. We didn’t discuss it but IMO, didSet should get lowercased as well.

-Chris

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution