[swift-evolution] [swift-evolution-announce] [Accepted] SE-0011 Replace `typealias` keyword with `associatedtype` for associated type declarations
clattner at apple.com
Sat Jan 9 19:16:20 CST 2016
> On Jan 9, 2016, at 3:24 PM, Kevin Ballard via swift-evolution <swift-evolution at 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.
More information about the swift-evolution