<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 Mar 16, 2016, at 12:23 PM, Russ Bishop &lt;<a href="mailto:xenadu@gmail.com" class="">xenadu@gmail.com</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=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Mar 9, 2016, at 8:47 PM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class="">This is a minimal proposal for introducing type aliases into Swift, and intentionally chooses to keep them limited to being “aliases”. &nbsp;As such, additional constraints are not allowed in this base proposal, e.g. you can’t write:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco;" class="">&nbsp; &nbsp; typealias StringDictionary&lt;T where T : Hashable&gt; = Dictionary&lt;String, T&gt;</div><div class=""><br class=""></div></div></div></div></blockquote><br class=""></div><div class="">What is the rationale for not supporting constraints? Generic type aliases have value without constraints but I can also see a lot of uses for allowing them, especially in some cases where the type constraints are fairly complex and repetitive. It also serves the same self-documenting-code purposes.</div><div class=""><br class=""></div><div class="">In this example it would be nonsense to have a “MatcherFunction” that can’t compare values. Why not express that in the constraint?</div><div class=""><br class=""></div><div class=""><font face="Monaco" class="">&nbsp; &nbsp; typealias MatcherFunction&lt;T where T : Comparable&gt; = (T, T) -&gt; MatchResult</font></div></div></div></blockquote><br class=""></div><div>I totally see the value in extending the model to support this. &nbsp;My rationale for excluding it from the initial proposal is to start with something that is “obvious” to get the feature in, then allow the more controversial pieces to be discussed as independent extensions, which can be motivated by specific use cases as necessary.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>