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

Chris Lattner 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.

-Chris



More information about the swift-evolution mailing list