<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 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=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">As SE-0011 states, the concept of <b class="">typealias</b> 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 <i class="">other </i>typealias be redefined to <b class="">typedef</b>, it's pretty clear that in use, what's being described in the second case is an <i class="">associated type. </i>The word <i class="">associated </i>means related to or connected to, and <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> 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 <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 style="font-family: Palatino-Roman;" class=""><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 <i class="">required</i> protocol members, like a property, method, initializer, or subscript requirement. They aren't implemented by a conforming construct or extension. </div></div></div></blockquote><div><br class=""></div><div>I don’t see how this:</div><div><br class=""></div><div>protocol P {</div><div> type/*alias*/ A</div><div>}</div><div><br class=""></div><div>struct X : P {</div><div> struct A {}</div><div>}</div><div><br class=""></div>is fundamentally any different from:</div><div><br class=""></div><div><div>protocol P {</div><div> func f()</div><div>}</div><div><br class=""></div><div>struct X : P {</div><div> func f() {}</div><div>}</div><div class=""><br class=""></div><div class="">What am I missing?</div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><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> in <font face="Menlo" class="">CollectionType</font>. </div></div></div></blockquote><div><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><div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div 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. </div><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" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""><div class="">
-Dave<div class=""><br class=""></div><br class="Apple-interchange-newline">
</div>
<br class=""></body></html>