> On Dec 22, 2015, at 5:51 PM, Erica Sadun <[email protected]> wrote: > >> >> On Dec 22, 2015, at 6:25 PM, Dave Abrahams <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution >>> <[email protected] <mailto:[email protected]>> 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.
I’m sorry, I’m missing your metaphor. > They provide a fundamental grammar for other tasks. Yes, other requirements may depend on associated types. They’re still requirements. > 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 > > <https://gist.githubusercontent.com/erica/c50f8f213db1be3e6390/raw/2888276fcad56d68016f864e6e0e9f689f597aac/0%20Conformances%20and%20Associated%20Types> Sorry, I’m not sure what insight that list is supposed to spark. Be assured, I have generated many such tables, graphs, etc. for myself in the past :-) >>> 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. Undeniably. > -- E > > >>> >>> -- E >>> >>> >>>> On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> 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 >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> -Dave -Dave
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
