> On Dec 23, 2015, at 8:34 AM, Chris Lattner via swift-evolution
> <[email protected]> wrote:
>
>
>> On Dec 23, 2015, at 2:08 AM, Brent Royal-Gordon via swift-evolution
>> <[email protected]> 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
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
-Dave
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
