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 <[email protected]> wrote: > > >> On Dec 22, 2015, at 11:05 AM, Matt Whiteside via swift-evolution >> <[email protected]> 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 > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
