<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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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.&nbsp;</div><div class=""><ul class=""><li class="">In one case, it's really just typedef.&nbsp;</li><li class="">In the other it's a stand-in for a deferred type that is specified by conforming classes.&nbsp;</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.&nbsp;</i>The word <i class="">associated </i>means related to or connected to, and <i class="">type</i>&nbsp;well it's a type. It &nbsp;basically says "this is a placeholder type that establishes a specific role in this protocol". I think&nbsp;<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.&nbsp;</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&nbsp;<b class="">associated types</b>&nbsp;as part of the protocol’s definition. An&nbsp;<b class="">associated type</b>&nbsp;gives a placeholder name (or alias) to a type that is used as part of the protocol. The actual type to use for that&nbsp;<b class="">associated type</b>&nbsp;is not specified until the protocol is adopted."</div><div class=""><br class=""></div><div class="">Some argue for raw <b class="">type</b>&nbsp;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. &nbsp;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>"&nbsp;</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>&nbsp; type/*alias*/ A</div><div>}</div><div><br class=""></div><div>struct X : P {</div><div>&nbsp; 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>&nbsp; func f()</div><div>}</div><div><br class=""></div><div>struct X : P {</div><div>&nbsp; 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:&nbsp;<font face="Menlo" class="">typealias Generator : GeneratorType = IndexingGenerator&lt;Self&gt;</font> in <font face="Menlo" class="">CollectionType</font>.&nbsp;</div></div></div></blockquote><div><br class=""></div>The way defaults are specified is a non-uniformity that we want to fix. &nbsp;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&nbsp;<b class="">typestandin,&nbsp;</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&nbsp;</b>for this proposal.&nbsp;</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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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 &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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=""> &nbsp;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>