[swift-evolution] [SE-0011] Re-considering the replacement keyword for "typealias"
mwhiteside.dev at gmail.com
Tue Dec 22 22:10:52 CST 2015
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”.
> 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
More information about the swift-evolution