<html><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><b class="">What is your evaluation of the proposal?</b><br class=""><br class=""><div class="">In favor.<br class=""><br class="">Overloading the meaning of “typealias” adds confusion to what is already a confusing feature of the language. The&nbsp;keyword “associatedtype” is much clearer — and much more searchable, helping newcomers to this feature discover&nbsp;the relevant documentation.<br class=""><br class="">The words “associated type” are easily the best of any alternatives proposed. Others (“associated”, “type”, etc.) are&nbsp;all either too vague or too obtuse, and many are likely to cause identifier collisions. No other terminology mentioned in&nbsp;the discussion comes in even a close second for me.<br class=""><br class="">What about the all lower case “associatedtype”? The underscore alternative of “associated_type” breaks existing language precedent. The camel case version&nbsp;(“associatedType”) does have language precedent, and I wonder if it wouldn’t be a better choice:<br class=""><br class="">&nbsp; &nbsp;&nbsp;dynamicType<br class="">&nbsp; &nbsp; didSet<br class="">&nbsp; &nbsp; willSet<br class=""><br class="">However, there’s also precedent for making paired words all lowercase in keywords:<br class=""><br class="">&nbsp; &nbsp; typealias<br class="">&nbsp; &nbsp; fallthrough<br class="">&nbsp; &nbsp; deinit &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ←(debatable: could be considered single word or hyphenated)<br class=""><br class="">Perhaps keyword capitalization conventions deserve some attention across the board.<br class=""><br class="">Regardless, I can happily accept “associatedtype.”<br class=""><br class=""><br class=""><b class="">Is the problem being addressed significant enough to warrant a change to Swift?</b><br class=""></div><div class=""><br class=""></div><div class="">Certainly. Associated types clearly are a point of confusion, and active evolution. Anything that clarifies their meaning is worth considering.</div><div class=""><br class=""></div><div class=""><div class=""><b class=""><br class=""></b></div><div class=""><b class="">Does this proposal fit well with the feel and direction of Swift?</b><br class=""></div></div><div class=""><b class=""><br class=""></b></div><div class="">Swift’s other keywords tend to favor the transparently descriptive (mutating, didSet) over the jargon-y (const, volatile). This change fits that tendency.<br class=""><br class=""><br class=""><div class=""><b class="">If you have you used other languages or libraries with a similar feature, how do you feel that this proposal compares&nbsp;to those?<br class=""></b></div><div class=""><br class=""></div>I haven’t, at least not enough to give useful insight..<br class=""><br class=""><br class=""><div class=""><b class="">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</b><br class=""></div><br class=""></div><div class="">I loosely followed the discussion thread.</div><div class=""><br class=""></div><div class="">Cheers,</div><div class=""><br class=""></div><div class="">Paul</div><div class=""><br class=""></div></body></html>