> On Dec 22, 2015, at 11:30 AM, Erica Sadun via swift-evolution > <swift-evolution@swift.org> wrote: > > As SE-0011 states, the concept of typealias is overloaded. > In one case, it's really just typedef. > In the other it's a stand-in for a deferred type that is specified by > conforming classes. > While you could argue that the other typealias be redefined to typedef, it's > pretty clear that in use, what's being described in the second case is an > associated type. The word associated means related to or connected to, and > type well it's a type. It basically says "this is a placeholder type that > establishes a specific role in this protocol". I think associatedtype is a > pretty good word to describe what a second-style typealias does: a conforming > construct binds an associated type with an actual type instance. > > The phrase "associated type" is used throughout the Swift Programming > Language book, for example: "When defining a protocol, it is sometimes useful > to declare one or more associated types as part of the protocol’s definition. > An associated type gives a placeholder name (or alias) to a type that is used > as part of the protocol. The actual type to use for that associated type is > not specified until the protocol is adopted." > > Some argue for raw type as the replacement: > Dave Abrahams writes, "I’m actually coming around to wanting it to be just > “type” as a contextual keyword, if we can make that work. The point is that > these types aren’t “associated” in any way that distinguishes them from other > requirements on nested declarations, i.e. funcs and vars." > Joe Groff writes, "Yeah, if we could make 'type' work I'd prefer that too. > None of our other protocol requirement declarations specifically call out the > fact that they're protocol requirements, so it feels a bit weird to use a > name like 'associatedtype' or 'requiredsomething' that belabors the > relationship between the protocol and the requirement." > Type members are unlike the other kinds of required protocol members, like a > property, method, initializer, or subscript requirement. They aren't > implemented by a conforming construct or extension. They act as stand-in or > placeholder: assigned not implemented. They can even be assigned as a default > in the protocol definition, for example: typealias Generator : GeneratorType > = IndexingGenerator<Self> in CollectionType. > > Unless typestandin, typeplaceholder, or adoptedtype are placed on the table, > I don't really see any reason to introduce a keyword other than > associatedtype for this proposal.
+1. associatedtype seems better than any other option I’ve seen thus far (including the new ones you mentioned). > > -- E > > >> On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >>> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> When you're actually implementing a generic function, the generic parameter >>> is [snip] >> >> Here's a word with meaning: parameter. Everything else I've seen sounds >> vague or approximate. Using the idea of a parameter would solidify the >> conceptual relationship between protocols-with-associated-types and generics. >> >> protocol P { >> parameter T >> } >> >> Guillaume Lessard >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
