<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 keyword “associatedtype” is much clearer — and much more searchable, helping newcomers to this feature discover the relevant documentation.<br class=""><br class="">The words “associated type” are easily the best of any alternatives proposed. Others (“associated”, “type”, etc.) are all either too vague or too obtuse, and many are likely to cause identifier collisions. No other terminology mentioned in 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 (“associatedType”) does have language precedent, and I wonder if it wouldn’t be a better choice:<br class=""><br class=""> dynamicType<br class=""> didSet<br class=""> willSet<br class=""><br class="">However, there’s also precedent for making paired words all lowercase in keywords:<br class=""><br class=""> typealias<br class=""> fallthrough<br class=""> deinit ←(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 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>