<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 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>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><br class=""></div><div>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><br class=""></div><div><font face="Monaco" class="">&nbsp; &nbsp; typealias MatcherFunction&lt;T where T : Comparable&gt; = (T, T) -&gt; MatchResult</font></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div><br class=""></div><div>Russ</div><br class=""></body></html>