<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 22, 2015, at 6:25 PM, Dave Abrahams <<a href="mailto:dabrahams@apple.com" class="">dabrahams@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Dec 22, 2015, at 9:30 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">As SE-0011 states, the concept of<span class="Apple-converted-space"> </span><b class="">typealias</b><span class="Apple-converted-space"> </span>is overloaded. </div><div class=""><ul class=""><li class="">In one case, it's really just typedef. </li><li class="">In the other it's a stand-in for a deferred type that is specified by conforming classes. </li></ul></div><div class="">While you could argue that the<span class="Apple-converted-space"> </span><i class="">other<span class="Apple-converted-space"> </span></i>typealias be redefined to<span class="Apple-converted-space"> </span><b class="">typedef</b>, it's pretty clear that in use, what's being described in the second case is an<span class="Apple-converted-space"> </span><i class="">associated type. </i>The word<span class="Apple-converted-space"> </span><i class="">associated<span class="Apple-converted-space"> </span></i>means related to or connected to, and<span class="Apple-converted-space"> </span><i class="">type</i> well it's a type. It basically says "this is a placeholder type that establishes a specific role in this protocol". I think <b class="">associatedtype</b><span class="Apple-converted-space"> </span>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. </div><div class=""><br class=""></div><div class="">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 <b class="">associated types</b> as part of the protocol’s definition. An <b class="">associated type</b> gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that <b class="">associated type</b> is not specified until the protocol is adopted."</div><div class=""><br class=""></div><div class="">Some argue for raw<span class="Apple-converted-space"> </span><b class="">type</b> as the replacement:</div><div class=""><ul class=""><li class="">Dave Abrahams writes, "<i class="">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.</i>"</li><li class="">Joe Groff writes, "<span class="" style="font-family: Palatino-Roman;"><i class="">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.</i>" </span></li></ul></div><div class="">Type members are unlike the other kinds of<span class="Apple-converted-space"> </span><i class="">required</i><span class="Apple-converted-space"> </span>protocol members, like a property, method, initializer, or subscript requirement. They aren't implemented by a conforming construct or extension.<span class="Apple-converted-space"> </span></div></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t see how this:</div><div class="">protocol P { type/*alias*/ A}</div><div class="">struct X : P { struct A {} }</div><div class=""><br class=""></div>is fundamentally any different from:</div><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class="">protocol P { func f()}</div><div class="">struct X : P { func f() {}}</div><div class=""><br class=""></div><div class="">What am I missing?</div></div></div></blockquote><div><br class=""></div><div>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.</div><div><br class=""></div><div>They provide a fundamental grammar for other tasks. </div><div><br class=""></div><div>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:</div><div><a href="https://gist.githubusercontent.com/erica/c50f8f213db1be3e6390/raw/2888276fcad56d68016f864e6e0e9f689f597aac/0%2520Conformances%2520and%2520Associated%2520Types" class="">https://gist.githubusercontent.com/erica/c50f8f213db1be3e6390/raw/2888276fcad56d68016f864e6e0e9f689f597aac/0%2520Conformances%2520and%2520Associated%2520Types</a></div><br class=""><blockquote type="cite" class=""><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">They act as stand-in or placeholder: assigned not implemented. They can even be assigned as a default in the protocol definition, for example: <font face="Menlo" class="">typealias Generator : GeneratorType = IndexingGenerator<Self></font><span class="Apple-converted-space"> </span>in<span class="Apple-converted-space"> </span><font face="Menlo" class="">CollectionType</font>. </div></div></div></blockquote><div class=""><br class=""></div>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.</div></blockquote><div><br class=""></div><div>Cool. Power to the protocol!</div><div><br class=""></div><blockquote type="cite" class=""><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Unless <b class="">typestandin, </b><b class="">typeplaceholder, </b>or <b class="">adoptedtype</b> are placed on the table, I don't really see any reason to introduce a keyword other than <b class="">associatedtype </b>for this proposal. <br class=""></div></blockquote><div><br class=""></div><div>And bringing a point from a later email: easier to google.</div><div><br class=""></div><div>-- E</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div><div class="">-- E</div><div class=""><br class=""></div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 22, 2015, at 8:40 AM, Guillaume Lessard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">On 21 déc. 2015, at 17:57, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">When you're actually implementing a generic function, the generic parameter is [snip]<br class=""></blockquote><br class="">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.<br class=""><br class="">protocol P {<br class=""> parameter T<br class="">}<br class=""><br class="">Guillaume Lessard<br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></div></blockquote></div><br class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=JfMPa-2F7wwZPzsZ3QKA8NjtONIYX4SjbWuUxtpfsTY2j4TkjKI013DkeL8UJTvpTT4CtskZTXs1YBxVkXkMUUk2TFfpo-2BcfYSQzA6NZ3ED1IU2HoAsq3R2Bcv0jmMYxAEajNshdie9YRVFjfnbN5ziXAqlwlgBFkBCVvloAHWomUVcHvjaKUEgiQoafQPd6809-2F5wYakd8G4lVL5RVapvB5JCgIOs0zuuJqjiE-2BKUAjM-3D" alt="" width="1" height="1" border="0" class="" style="height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;"></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class="" style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="" style="font-family: Palatino-Roman; font-size: 14px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">-Dave</div></blockquote></div><br class=""></body></html>