<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></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=""><br class=""></div><div class=""><div class="" style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="Apple-tab-span" style="white-space: pre;"> </span>* What is your evaluation of the proposal?<br class=""></div></div></blockquote><div><br class=""></div>+1</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="Apple-tab-span" style="white-space: pre;"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div></blockquote><div><br class=""></div><div>Yes. A typealias in a protocol and a typealias anywhere else are 2 very different things.</div><div><br class=""></div><div>* One is almost a preprocessor macro</div><div>* The other basically defines the protocol as a generic type, which has a lot of strange follow-on consequences</div><div><br class=""></div><div>There are <a href="http://stackoverflow.com/questions/27725803/how-to-use-generic-protocol-as-a-variable-type" class="">plenty</a> of <a href="https://groups.google.com/forum/#!topic/swift-language/jzElQYwe9sM" class="">questions</a> online related to this confusion.</div><div><br class=""></div><div>In addition the change is trivial and code could be transitioned automatically.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="Apple-tab-span" style="white-space: pre;"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></blockquote><div><br class=""></div><div>The choice of keyword "associatedtype" is already used in a common compiler error message:</div><div><br class=""></div><div><blockquote type="cite" class="">protocol 'Printable' can only be used as a generic constraint because it has Self or <b class="">associated type</b> requirements</blockquote></div><div><br class=""></div><div>Using "associatedtype" here is consistent with that error message and makes it more understandable for new users.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="" style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="Apple-tab-span" style="white-space: pre;"> </span>* 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=""></div></div></blockquote><div><br class=""></div><div>I am an occasional user of Rust; Rust uses the same keyword ("type") in both of these cases. IMO that choice is suffers from the same problems in Rust that it does here.</div></div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="" style="font-family: HelveticaNeue; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="Apple-tab-span" style="white-space: pre;"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</div></div></blockquote></div><div class=""><br class=""></div><div class="">One "potential" problem with this proposal is that it technically forbids the use of a "real" typealias in a protocol e.g.</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">protocol Foo {</div><div class=""> typealias F = Int</div><div class="">}</div></blockquote><div class=""><br class=""></div>is now illegal.<br class=""><div class=""><br class=""></div><div class="">To evaluate the severity of this problem I checked a private codebase with 47 usages of typealias. One usage of the 47 would be illegal:</div><div class=""><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div class="">protocol Foo {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span> #if arch(x86_64) || arch(arm64)</div> typealias secondstype = Int64<br class=""> typealias usecstype = Int64<br class=""> #else<br class=""> typealias secondstype = __darwin_time_t<br class=""> typealias usecstype = __darwin_suseconds_t<br class=""> #endif<div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func setTimeout(s: secondstype, u: usecstype) throws</div><div class=""><div class="">}</div></div></blockquote><div class=""><div class=""><br class=""></div><div class="">I refactored this to move the typealiases to top level. That is not ideal, but I think it is outweighed by the advantages of this proposal.</div></div><div class=""><br class=""></div><div class="">While auditing this codebase for illegal typealiases I did find a comment that was quite confused about the difference between typealias and associatedtype. So that convinces me even more about the importance of this proposal.</div></body></html>