<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 11: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. 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 class=""><br class=""></div><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></div></blockquote><div><br class=""></div><div>+1. associatedtype seems better than any other option I’ve seen thus far (including the new ones you mentioned).</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=""><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=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAckQnPtQK5dYeBjFFWgTwRJzBAlkJxuVXiB-2BmFE-2ByPfVZisRkZ9fl-2FWpPhp5LIukitanWt4W0oXTqNl-2FD-2BZP2l-2Bc92kQIymo1i9S3j4bSpO0KDY9TYRPT-2B5r-2BspShV2VPvz-2Be5dDQm2dVPJJlYZxviwVuJZxBLMWdIfuCmaXLUFYShSexGcgF8IPFNRo-2FG-2F2VU-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=""></body></html>