> On Dec 22, 2015, at 6:25 PM, Dave Abrahams <dabrah...@apple.com> wrote: > >> >> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution >> <swift-evolution@swift.org <mailto: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. > > I don’t see how this: > protocol P { type/*alias*/ A} > struct X : P { struct A {} } > > is fundamentally any different from: > protocol P { func f()} > struct X : P { func f() {}} > > What am I missing?
You're not using func f() elsewhere as a return type, a parameter type, in generic constraints, etc. Other member requirements are Jeff Goldblum and typealiases are Chuck Norris. They provide a fundamental grammar for other tasks. Quick reference I ended up generating so I could keep all of my possible expressiveness at hand. It may or may not add to your thoughts about this: https://gist.githubusercontent.com/erica/c50f8f213db1be3e6390/raw/2888276fcad56d68016f864e6e0e9f689f597aac/0%2520Conformances%2520and%2520Associated%2520Types >> 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. > > The way defaults are specified is a non-uniformity that we want to fix. > There’s no reason we couldn’t be providing default implementations of > required protocol methods in the protocol body either. Cool. Power to the protocol! > 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. And bringing a point from a later email: easier to google. -- E >> >> -- 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 >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > -Dave
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
