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

[Matt Whiteside]

Yes, true, it’s not quite a parameter because it can’t vary.  But in the sense that it’s a slot that you have to provide a value for, you might call it a parameter.  Having the syntax be “type parameter” gives a further hint that there’s more to it than a regular parameter.

But having said that, everything in a protocol is a slot that you have to provide a value for, so that makes me think that just plain “type” may be better after all, which is the way I’m now leaning.

“associated type” has some good points too, e.g., that is what the feature is called.  It just seems a little redundant, and verbose.  We already know it’s associated because it’s inside the braces.  It doesn’t say anything about the nature of the association, which is: “this is something you have to fill in”.  I don’t see any problem in referring to the feature as associated types, but then having the syntax be just plain “type”.

Matt


> On Dec 22, 2015, at 18:01, Douglas Gregor <dgregor at apple.com> wrote:
> 
> 
>> On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> “parameter” is a good thought.  On it’s own it seems like it’s missing something though.  But it gives me other ideas: “typeparam”, “type param", “typeparameter”, or “type parameter”.
> 
> 
> It’s not a parameter, though, because it does not vary the way a parameter does: a given type X cannot conform to a protocol with two different bindings for a given associated type.
> 
> 	- Doug
>