[swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"

[Dave Abrahams]

> On Dec 23, 2015, at 12:41 PM, Chris Lattner <clattner at apple.com> wrote:
> 
> On Dec 23, 2015, at 10:25 AM, Dave Abrahams <dabrahams at apple.com> wrote:
>>> Of the three, I prefer “associatedtype”.
>>> 
>>> We already have precedent for concatenated names in a very related sort of decl (typealias), and this will be a real keyword.
>>> 
>>> 
>>> Here are how I see the pros and cons I see of these options:
>>> 
>>> type:
>>> - Overly short, particularly given the infrequency of these decls, the common case of “type Element” will be weird floating around given its lack of weight.
>> 
>> I don’t understand how that’s different from, e.g.
>> 
>> 	init()
>> 
>> or
>> 
>>       var x: Int
>> 
>> which will both show up in protocol declarations.  Could you explain?
> 
> It follows from the same logic that makes “typealias” have a long name, instead of being named “type” or “typ” ;-)
> 
> typealiases and associated types are both *much* less frequently used than variables or functions.  var and func make sense to keep very short because of their frequency, and because every swift programmer is expected to memorize what they do.  “init” is less defensible on these terms, because it is more rare, but is clear, and shares commonality with some ObjC heritage.
> 
> If you compare typealiases and associated types, these are *much* more infrequently used than any of these three, they are effectively a advanced generics feature.  Because they are less frequent, people shouldn’t be expected to memorize what they are, and googlability does matter.
> 
> 
>>> - Overly unclear.  This is a very specific kind of type, not a generic type you can use in other contexts.
>> 
>> Could you explain what you mean by this?  If anything I see this exactly opposite.  It’s a requirement for a type, *any* kind of type, be it struct, class, enum, non-nominal type such as tuple or function, whatever—so long as it satisfies the constraints placed it.  That’s about as generic as one can get.
> 
> This is a declaration of a requirement of a type.  This is not declaring a type.  This keyword cannot be used in any other place in the grammar.  People would reasonably expect to use a keyword like “type” elsewhere.  This keyword is completely different than init/var/func in that sense.
> 
>>> - Unfortunate keyword.  Among other things it would make writing compilers in swift a pain :-), but again, people would want to use this in other places.
>> 
>> I don’t see how this would actually cause a problem if it was contextual.  
> 
> Besides the parser ambiguities?  We could probably force it to work, but it would be unnecessary complexity.  All statements and decls should start with a keyword.  This enables attributes and declmodifiers to “just work”, you lose that if you play games with context sensitive keywords.
> 
>> There’s no reason one couldn’t name a property “type” if one wanted to.  These two things will appear in *very* different contexts, so I don’t think humans would have a hard time de-contextualizing.
> 
> I agree, that’s exactly why I don’t think it should be called “type”.  They are very different things.

Thanks for explaining, Chris.

-Dave