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

[Douglas Gregor]

Sent from my iPhone

> On Jan 9, 2016, at 5:33 PM, Kevin Ballard via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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

> -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 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution