<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>+1</div><div>This is very welcome!</div><div><br></div><div>-Thorsten&nbsp;</div><div><br>Am 10.03.2016 um 05:47 schrieb Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt;:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class="">Hi All,</div><div class=""><br class=""></div><div class="">I’ve started prototyping generic type aliases in master, but we’d like to run this through the evolution process for discussion. &nbsp;Comments and discussion are welcome. &nbsp;Here’s the start of the email thread for the actual formal proposal:</div><div class=""><br class=""></div><div class=""><b class=""><br class=""></b></div><b class="">Introduction</b><br class=""><br class="">This proposal aims to add generic typealiases to Swift.<br class=""><br class="">Swift-evolution thread:&nbsp;&lt;you are here&gt;<br class=""><br class=""><b class="">Motivation</b><br class=""><br class="">Generic typealiases are a somewhat obvious generalization of the existing Swift model for type aliases, which allow you to provide a name for an existing nominal generic type, or to provide a name for a non-nominal type (e.g. tuples, functions, etc) with generic parameters.<div class=""><br class=""></div><div class=""><b class="">Proposed solution</b><br class=""><br class="">The solution solution is straight-forward: allow type aliases to introduce type parameters, which are in scope for their definition. &nbsp;This allows one to express things like:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco;" class="">&nbsp; &nbsp;&nbsp;typealias StringDictionary&lt;T&gt; = Dictionary&lt;String, T&gt;</div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco;" class="">&nbsp; &nbsp; typealias IntFunction&lt;T&gt; = (T) -&gt; Int</div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco;" class="">&nbsp; &nbsp; typealias MatchingTriple&lt;T&gt; = (T, T, T)</div><div style="margin: 0px; font-size: 10px; line-height: normal; font-family: Monaco;" class="">&nbsp; &nbsp; typealias BackwardTriple&lt;T1,T2,T3&gt; = (T3, T2, T1)</div><div class=""><br class=""></div>This is consistent with the rest of Swift’s approach to generics, and slots directly into the model.</div><div class=""><br class=""><b class="">Detailed design</b><br 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 class="">Otherwise, generic type aliases follow the model of type aliases and the precedent of the other generic declarations in Swift. &nbsp;For example, they allow the usual access control features that type aliases support. &nbsp;Similarly, like non-generic type aliases, generic type aliases cannot be “resilient”.</div><br class=""><b class="">Impact on existing code</b><br class=""><br class="">This is a new feature, so there is no impact on existing code.<br class=""><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>