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

[Dave Abrahams]

> On Dec 23, 2015, at 8:34 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Dec 23, 2015, at 2:08 AM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>>> I did see that point made earlier in the thread, but I’m not convinced that design for googleability is the right ordering of priorities. 
>>> +1
>>> Choosing cryptic names because it's easier to find information about them is bad. With this argument, you can not only fight against removal of the NextStep prefix (Data, Number, Date… try googling that), but also demand that the language should be spelled "Sweeft", and that framework functions should loose their meaningful names and get called by a UUID instead.
>> 
>> I don't think the `associated` keyword is cryptic; I think it's *specific*. "Associated type" is the name of this feature. We tried bikeshedding it upthread, and didn't come up with anything better. If you're going to use a keyword related to the name "associated type", that leaves you with `associated`, `type`, or `associatedtype`. 
> 
> 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?

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

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

> associated:
> - Vacuous: doesn’t mean anything on its own:  “associated Element”.

Heh, now that I look at that, provided we can be consistent about only UpperCamelCasing type names it actually might be sufficiently communicative.  Just a thought.

> - Somewhat unfortunate as a keyword, but much less so than type.
> 
> associatedtype:
> - Clean in context: “associatedtype Element”
> - Obvious you wouldn’t want to use it in another context.
> - Googlable, unambiguous
> 
> -Chris
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-Dave