[swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"
clattner at apple.com
Wed Dec 23 10:34:15 CST 2015
> 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.
>> 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:
- 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.
- Overly unclear. This is a very specific kind of type, not a generic type you can use in other contexts.
- 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.
- Vacuous: doesn’t mean anything on its own: “associated Element”.
- Somewhat unfortunate as a keyword, but much less so than type.
- Clean in context: “associatedtype Element”
- Obvious you wouldn’t want to use it in another context.
- Googlable, unambiguous
More information about the swift-evolution