<div dir="ltr"><div>Sorry about dredging up an older topic! I was trying to search through the mailing list to figure out the right place to reference and this seemed as good as any... Also this is the first mailing list I&#39;ve ever joined and first e-mail on said list so please forgive me if I&#39;m doing this wrong!</div><div><br></div><div>I wanted to ask a question on the future of doing Protocol-oriented programming in conjunction with generics. Disclosure, I&#39;ve worked a lot with C# so this would be the same idea as Interface oriented programming in combination with Generics there.</div><div><br></div><div>Is there currently a way to do dependency injection using protocols with generics? I&#39;ve linked to a StackOverflow question below that I&#39;ve asked regarding this topic (again if that is a f<span style="white-space:nowrap">aux pas I apologize).</span></div><div><br></div><a href="http://stackoverflow.com/questions/38619660/is-it-possible-to-pass-generic-protocols-into-a-constructor-for-proper-dependenc">http://stackoverflow.com/questions/38619660/is-it-possible-to-pass-generic-protocols-into-a-constructor-for-proper-dependenc</a><div><br></div><div><span style="white-space:nowrap">The main aspect that I&#39;m interested in getting to is being able to properly mock and unit test my code using dependency injection and Protocols. This is a very, very useful way to architect your code in such a way as to easily facilitate this kind of unit testing in conjunction with Mocking.</span></div><div><span style="white-space:nowrap"><br></span></div><div><span style="white-space:nowrap">Please let me know if I&#39;m completely missing the boat here!</span></div><div><span style="white-space:nowrap"><br></span></div><div><span style="white-space:nowrap">Thanks,</span></div><div><span style="white-space:nowrap"><br></span></div><div><span style="white-space:nowrap">Patrick<br></span><div><br></div><div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Hi all,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Introduction</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The “Complete Generics” goal for Swift 3 has been fairly ill-defined thus fair, with just this short blurb in the list of goals:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Complete generics: Generics are used pervasively in a number of Swift libraries, especially the standard library. However, there are a number of generics features the standard library requires to fully realize its vision, including recursive protocol constraints, the ability to make a constrained extension conform to a new protocol (i.e., an array of Equatable elements is Equatable), and so on. Swift 3.0 should provide those generics features needed by the standard library, because they affect the standard library&#39;s ABI.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; This message expands upon the notion of “completing generics”. It is not a plan for Swift 3, nor an official core team communication, but it collects the results of numerous discussions among the core team and Swift developers, both of the compiler and the standard library. I hope to achieve several things:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Communicate a vision for Swift generics, building on the original generics design document&lt;<a href="https://github.com/apple/swift/blob/master/docs/Generics.rst">https://github.com/apple/swift/blob/master/docs/Generics.rst</a>&gt;, so we have something concrete and comprehensive to discuss.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Establish some terminology that the Swift developers have been using for these features, so our discussions can be more productive (“oh, you’re proposing what we refer to as ‘conditional conformances’; go look over at this thread”).</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Engage more of the community in discussions of specific generics features, so we can coalesce around designs for public review. And maybe even get some of them implemented.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; A message like this can easily turn into a centithread&lt;<a href="http://www.urbandictionary.com/define.php?term=centithread">http://www.urbandictionary.com/define.php?term=centithread</a>&gt;. To separate concerns in our discussion, I ask that replies to this specific thread be limited to discussions of the vision as a whole: how the pieces fit together, what pieces are missing, whether this is the right long-term vision for Swift, and so on. For discussions of specific language features, e.g., to work out the syntax and semantics of conditional conformances or discuss the implementation in compiler or use in the standard library, please start a new thread based on the feature names I’m using.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; This message covers a lot of ground; I’ve attempted a rough categorization of the various features, and kept the descriptions brief to limit the overall length. Most of these aren’t my ideas, and any syntax I’m providing is simply a way to express these ideas in code and is subject to change. Not all of these features will happen, either soon or ever, but they are intended to be a fairly complete whole that should mesh together. I’ve put a * next to features that I think are important in the nearer term vs. being interesting “some day”. Mostly, the *’s reflect features that will have a significant impact on the Swift standard library’s design and implementation.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Enough with the disclaimers; it’s time to talk features.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Removing unnecessary restrictions</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; There are a number of restrictions to the use of generics that fall out of the implementation in the Swift compiler. Removal of these restrictions is a matter of implementation only; one need not introduce new syntax or semantics to realize them. I’m listing them for two reasons: first, it’s an acknowledgment that these features are intended to exist in the model we have today, and, second, we’d love help with the implementation of these features.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; *Recursive protocol constraints</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Currently, an associated type cannot be required to conform to its enclosing protocol (or any protocol that inherits that protocol). For example, in the standard library SubSequence type of a Sequence should itself be a Sequence:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol Sequence {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype Iterator : IteratorProtocol</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; …</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype SubSequence : Sequence // currently ill-formed, but should be possible</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The compiler currently rejects this protocol, which is unfortunate: it effectively pushes the SubSequence-must-be-a-Sequence requirement into every consumer of SubSequence, and does not communicate the intent of this abstraction well.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Nested generics</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Currently, a generic type cannot be nested within another generic type, e.g.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; struct X&lt;T&gt;{</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; struct Y&lt;U&gt;{ } // currently ill-formed, but should be possible</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; There isn’t much to say about this: the compiler simply needs to be improved to handle nested generics throughout.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Concrete same-type requirements</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Currently, a constrained extension cannot use a same-type constraint to make a type parameter equivalent to a concrete type. For example:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension Array where Element == String {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func makeSentence() -&gt;String {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; // uppercase first string, concatenate with spaces, add a period, whatever</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; This is a highly-requested feature that fits into the existing syntax and semantics. Note that one could imagine introducing new syntax, e.g., extending “Array&lt;String&gt;”, which gets into new-feature territory: see the section on “Parameterized extensions”.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Parameterizing other declarations</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; There are a number of Swift declarations that currently cannot have generic parameters; some of those have fairly natural extensions to generic forms that maintain their current syntax and semantics, but become more powerful when made generic.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Generic typealiases</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Typealiases could be allowed to carry generic parameters. They would still be aliases (i.e., they would not introduce new types). For example:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; typealias StringDictionary&lt;Value&gt;= Dictionary&lt;String, Value&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var d1 = StringDictionary&lt;Int&gt;()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var d2: Dictionary&lt;String, Int&gt;= d1 // okay: d1 and d2 have the same type, Dictionary&lt;String, Int&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Generic subscripts</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Subscripts could be allowed to have generic parameters. For example, we could introduce a generic subscript on a Collection that allows us to pull out the values at an arbitrary set of indices:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension Collection {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; subscript&lt;Indices: Sequence where Indices.Iterator.Element == Index&gt;(indices: Indices) -&gt;[Iterator.Element] {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; get {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var result = [Iterator.Element]()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; for index in indices {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; result.append(self[index])</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return result</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; set {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; for (index, value) in zip(indices, newValue) {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; self[index] = value</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Generic constants</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let constants could be allowed to have generic parameters, such that they produce differently-typed values depending on how they are used. For example, this is particularly useful for named literal values, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let π&lt;T : FloatLiteralConvertible&gt;: T = 3.141592653589793238462643383279502884197169399</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The Clang importer could make particularly good use of this when importing macros.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Parameterized extensions</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Extensions themselves could be parameterized, which would allow some structural pattern matching on types. For example, this would permit one to extend an array of optional values, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension&lt;T&gt;Array where Element == T? {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var someValues: [T] {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var result = [T]()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; for opt in self {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if let value = opt { result.append(value) }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return result</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; We can generalize this to a protocol extensions:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension&lt;T&gt;Sequence where Element == T? {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var someValues: [T] {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var result = [T]()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; for opt in self {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if let value = opt { result.append(value) }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return result</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Note that when one is extending nominal types, we could simplify the syntax somewhat to make the same-type constraint implicit in the syntax:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension&lt;T&gt;Array&lt;T?&gt;{</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var someValues: [T] {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var result = [T]()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; for opt in self {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if let value = opt { result.append(value) }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return result</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; When we’re working with concrete types, we can use that syntax to improve the extension of concrete versions of generic types (per “Concrete same-type requirements”, above), e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension Array&lt;String&gt;{</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func makeSentence() -&gt;String {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; // uppercase first string, concatenate with spaces, add a period, whatever</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Minor extensions</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; There are a number of minor extensions we can make to the generics system that don’t fundamentally change what one can express in Swift, but which can improve its expressivity.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; *Arbitrary requirements in protocols</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Currently, a new protocol can inherit from other protocols, introduce new associated types, and add new conformance constraints to associated types (by redeclaring an associated type from an inherited protocol). However, one cannot express more general constraints. Building on the example from “Recursive protocol constraints”, we really want the element type of a Sequence’s SubSequence to be the same as the element type of the Sequence, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol Sequence {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype Iterator : IteratorProtocol</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; …</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype SubSequence : Sequence where SubSequence.Iterator.Element == Iterator.Element</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Hanging the where clause off the associated type is protocol not ideal, but that’s a discussion for another thread.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; *Typealiases in protocols and protocol extensions</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Now that associated types have their own keyword (thanks!), it’s reasonable to bring back “typealias”. Again with the Sequence protocol:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol Sequence {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype Iterator : IteratorProtocol</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; typealias Element = Iterator.Element // rejoice! now we can refer to SomeSequence.Element rather than SomeSequence.Iterator.Element</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Default generic arguments</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Generic parameters could be given the ability to provide default arguments, which would be used in cases where the type argument is not specified and type inference could not determine the type argument. For example:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public final class Promise&lt;Value, Reason=Error&gt;{ … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func getRandomPromise() -&gt;Promise&lt;Int, ErrorProtocol&gt;{ … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var p1: Promise&lt;Int&gt;= …</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var p2: Promise&lt;Int, Error&gt;= p1 // okay: p1 and p2 have the same type Promise&lt;Int, Error&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var p3: Promise = getRandomPromise() // p3 has type Promise&lt;Int, ErrorProtocol&gt;due to type inference</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Generalized “class” constraints</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The “class” constraint can currently only be used for defining protocols. We could generalize it to associated type and type parameter declarations, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol P {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype A : class</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo&lt;T : class&gt;(t: T) { }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; As part of this, the magical AnyObject protocol could be replaced with an existential with a class bound, so that it becomes a typealias:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; typealias AnyObject = protocol&lt;class&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; See the “Existentials” section, particularly “Generalized existentials”, for more information.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; *Allowing subclasses to override requirements satisfied by defaults</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; When a superclass conforms to a protocol and has one of the protocol’s requirements satisfied by a member of a protocol extension, that member currently cannot be overridden by a subclass. For example:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol P {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension P {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo() { print(“P”) }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; class C : P {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; // gets the protocol extension’s</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; class D : C {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; /*override not allowed!*/ func foo() { print(“D”) }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let p: P = D()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; p.foo() // gotcha: prints “P” rather than “D”!</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; D.foo should be required to specify “override” and should be called dynamically.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Major extensions to the generics model</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Unlike the minor extensions, major extensions to the generics model provide more expressivity in the Swift generics system and, generally, have a much more significant design and implementation cost.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; *Conditional conformances</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Conditional conformances express the notion that a generic type will conform to a particular protocol only under certain circumstances. For example, Array is Equatable only when its elements are Equatable:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension Array : Equatable where Element : Equatable { }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func ==&lt;T : Equatable&gt;(lhs: Array&lt;T&gt;, rhs: Array&lt;T&gt;) -&gt;Bool { … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Conditional conformances are a potentially very powerful feature. One important aspect of this feature is how deal with or avoid overlapping conformances. For example, imagine an adaptor over a Sequence that has conditional conformances to Collection and MutableCollection:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; struct SequenceAdaptor&lt;S: Sequence&gt;: Sequence { }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension SequenceAdaptor : Collection where S: Collection { … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension SequenceAdaptor : MutableCollection where S: MutableCollection { }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; This should almost certainly be permitted, but we need to cope with or reject “overlapping” conformances:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension SequenceAdaptor : Collection where S: SomeOtherProtocolSimilarToCollection { } // trouble: two ways for SequenceAdaptor to conform to Collection</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; See the section on “Private conformances” for more about the issues with having the same type conform to the same protocol multiple times.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Variadic generics</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Currently, a generic parameter list contains a fixed number of generic parameters. If one has a type that could generalize to any number of generic parameters, the only real way to deal with it today involves creating a set of types. For example, consider the standard library’s “zip” function. It returns one of these when provided with two arguments to zip together:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public struct Zip2Sequence&lt;Sequence1 : Sequence,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Sequence2 : Sequence&gt;: Sequence { … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public func zip&lt;Sequence1 : Sequence, Sequence2 : Sequence&gt;(</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; sequence1: Sequence1, _ sequence2: Sequence2)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; -&gt;Zip2Sequence&lt;Sequence1, Sequence2&gt;{ … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Supporting three arguments would require copy-paste of those of those:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public struct Zip3Sequence&lt;Sequence1 : Sequence,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Sequence2 : Sequence,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Sequence3 : Sequence&gt;: Sequence { … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public func zip&lt;Sequence1 : Sequence, Sequence2 : Sequence, Sequence3 : Sequence&gt;(</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; sequence1: Sequence1, _ sequence2: Sequence2, _ sequence3: sequence3)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; -&gt;Zip3Sequence&lt;Sequence1, Sequence2, Sequence3&gt;{ … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Variadic generics would allow us to abstract over a set of generic parameters. The syntax below is hopelessly influenced by C++11 variadic templates&lt;<a href="http://www.jot.fm/issues/issue_2008_02/article2/%3E(sorry)">http://www.jot.fm/issues/issue_2008_02/article2/&gt;(sorry)</a>, where putting an ellipsis (“…”) to the left of a declaration makes it a “parameter pack” containing zero or more parameters and putting an ellipsis to the right of a type/expression/etc. expands the parameter packs within that type/expression into separate arguments. The important part is that we be able to meaningfully abstract over zero or more generic parameters, e.g.:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public struct ZipIterator&lt;... Iterators : IteratorProtocol&gt;: Iterator { // zero or more type parameters, each of which conforms to IteratorProtocol</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public typealias Element = (Iterators.Element...) // a tuple containing the element types of each iterator in Iterators</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var (...iterators): (Iterators...) // zero or more stored properties, one for each type in Iterators</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var reachedEnd: Bool = false</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public mutating func next() -&gt;Element? {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if reachedEnd { return nil }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; guard let values = (iterators.next()...) { // call “next” on each of the iterators, put the results into a tuple named “values&quot;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; reachedEnd = true</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return nil</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return values</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public struct ZipSequence&lt;...Sequences : Sequence&gt;: Sequence {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public typealias Iterator = ZipIterator&lt;Sequences.Iterator...&gt;// get the zip iterator with the iterator types of our Sequences</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var (...sequences): (Sequences...) // zero or more stored properties, one for each type in Sequences</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; // details ...</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Such a design could also work for function parameters, so we can pack together multiple function arguments with different types, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public func zip&lt;... Sequences : SequenceType&gt;(... sequences: Sequences...)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; -&gt;ZipSequence&lt;Sequences...&gt;{</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return ZipSequence(sequences...)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Finally, this could tie into the discussions about a tuple “splat” operator. For example:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func apply&lt;... Args, Result&gt;(fn: (Args...) -&gt;Result, // function taking some number of arguments and producing Result</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; args: (Args...)) -&gt;Result { // tuple of arguments</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return fn(args...) // expand the arguments in the tuple “args” into separate arguments</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Extensions of structural types</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Currently, only nominal types (classes, structs, enums, protocols) can be extended. One could imagine extending structural types—particularly tuple types—to allow them to, e.g., conform to protocols. For example, pulling together variadic generics, parameterized extensions, and conditional conformances, one could express “a tuple type is Equatable if all of its element types are Equatable”:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension&lt;...Elements : Equatable&gt;(Elements...) : Equatable { // extending the tuple type “(Elements…)” to be Equatable</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; There are some natural bounds here: one would need to have actual structural types. One would not be able to extend every type:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension&lt;T&gt;T { // error: neither a structural nor a nominal type</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; And before you think you’re cleverly making it possible to have a conditional conformance that makes every type T that conforms to protocol P also conform to protocol Q, see the section &quot;Conditional conformances via protocol extensions”, below:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension&lt;T : P&gt;T : Q { // error: neither a structural nor a nominal type</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Syntactic improvements</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; There are a number of potential improvements we could make to the generics syntax. Such a list could go on for a very long time, so I’ll only highlight some obvious ones that have been discussed by the Swift developers.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; *Default implementations in protocols</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Currently, protocol members can never have implementations. We could allow one to provide such implementations to be used as the default if a conforming type does not supply an implementation, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol Bag {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype Element : Equatable</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func contains(element: Element) -&gt;Bool</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func containsAll&lt;S: Sequence where Sequence.Iterator.Element == Element&gt;(elements: S) -&gt;Bool {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; for x in elements {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if contains(x) { return true }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return false</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; struct IntBag : Bag {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; typealias Element = Int</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func contains(element: Int) -&gt;Bool { ... }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; // okay: containsAll requirement is satisfied by Bag’s default implementation</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; One can get this effect with protocol extensions today, hence the classification of this feature as a (mostly) syntactic improvement:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol Bag {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype Element : Equatable</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func contains(element: Element) -&gt;Bool</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func containsAll&lt;S: Sequence where Sequence.Iterator.Element == Element&gt;(elements: S) -&gt;Bool</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension Bag {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func containsAll&lt;S: Sequence where Sequence.Iterator.Element == Element&gt;(elements: S) -&gt;Bool {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; for x in elements {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if contains(x) { return true }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; return false</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; *Moving the where clause outside of the angle brackets</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The “where” clause of generic functions comes very early in the declaration, although it is generally of much less concern to the client than the function parameters and result type that follow it. This is one of the things that contributes to “angle bracket blindness”. For example, consider the containsAll signature above:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func containsAll&lt;S: Sequence where Sequence.Iterator.Element == Element&gt;(elements: S) -&gt;Bool</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; One could move the “where” clause to the end of the signature, so that the most important parts—name, generic parameter, parameters, result type—precede it:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func containsAll&lt;S: Sequence&gt;(elements: S) -&gt;Bool</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; where Sequence.Iterator.Element == Element</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; *Renaming “protocol&lt;…&gt;” to “Any&lt;…&gt;”.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The “protocol&lt;…&gt;” syntax is a bit of an oddity in Swift. It is used to compose protocols together, mostly to create values of existential type, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var x: protocol&lt;NSCoding, NSCopying&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; It’s weird that it’s a type name that starts with a lowercase letter, and most Swift developers probably never deal with this feature unless they happen to look at the definition of Any:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; typealias Any = protocol&lt;&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; “Any” might be a better name for this functionality. “Any” without brackets could be a keyword for “any type”, and “Any” followed by brackets could take the role of “protocol&lt;&gt;” today:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var x: Any&lt;NSCoding, NSCopying&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; That reads much better: “Any type that conforms to NSCoding and NSCopying”. See the section &quot;Generalized existentials” for additional features in this space.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Maybe</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; There are a number of features that get discussed from time-to-time, while they could fit into Swift’s generics system, it’s not clear that they belong in Swift at all. The important question for any feature in this category is not “can it be done” or “are there cool things we can express”, but “how can everyday Swift developers benefit from the addition of such a feature?”. Without strong motivating examples, none of these “maybes” will move further along.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Dynamic dispatch for members of protocol extensions</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Only the requirements of protocols currently use dynamic dispatch, which can lead to surprises:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol P {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension P {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo() { print(“P.foo()”)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func bar() { print(“P.bar()”)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; struct X : P {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo() { print(“X.foo()”)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func bar() { print(“X.bar()”)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let x = X()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; x.foo() // X.foo()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; x.bar() // X.bar()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let p: P = X()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; p.foo() // X.foo()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; p.bar() // P.bar()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Swift could adopt a model where members of protocol extensions are dynamically dispatched.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Named generic parameters</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; When specifying generic arguments for a generic type, the arguments are always positional: Dictionary&lt;String, Int&gt;is a Dictionary whose Key type is String and whose Value type is Int, by convention. One could permit the arguments to be labeled, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; var d: Dictionary&lt;Key: String, Value: Int&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Such a feature makes more sense if Swift gains default generic arguments, because generic argument labels would allow one to skip defaulted arguments.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Generic value parameters</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Currently, Swift’s generic parameters are always types. One could imagine allowing generic parameters that are values, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; struct MultiArray&lt;T, let Dimensions: Int&gt;{ // specify the number of dimensions to the array</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; subscript (indices: Int...) -&gt;T {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; get {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; require(indices.count == Dimensions)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; // ...</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; A suitably general feature might allow us to express fixed-length array or vector types as a standard library component, and perhaps also allow one to implement a useful dimensional analysis library. Tackling this feature potentially means determining what it is for an expression to be a “constant expression” and diving into dependent-typing, hence the “maybe”.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Higher-kinded types</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Higher-kinded types allow one to express the relationship between two different specializations of the same nominal type within a protocol. For example, if we think of the Self type in a protocol as really being “Self&lt;T&gt;”, it allows us to talk about the relationship between “Self&lt;T&gt;” and “Self&lt;U&gt;” for some other type U. For example, it could allow the “map” operation on a collection to return a collection of the same kind but with a different operation, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let intArray: Array&lt;Int&gt;= …</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; intArray.map { String($0) } // produces Array&lt;String&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let intSet: Set&lt;Int&gt;= …</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; intSet.map { String($0) } // produces Set&lt;String&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Potential syntax borrowed from one thread on higher-kinded types&lt;<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html%3Euses">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002736.html&gt;uses</a> ~= as a “similarity” constraint to describe a Functor protocol:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol Functor {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype A</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func fmap&lt;FB where FB ~= Self&gt;(f: A -&gt;FB.A) -&gt;FB</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Specifying type arguments for uses of generic functions</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The type arguments of a generic function are always determined via type inference. For example, given:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func f&lt;T&gt;(t: T)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; one cannot directly specify T: either one calls “f” (and T is determined via the argument’s type) or one uses “f” in a context where it is given a particular function type (e.g., “let x: (Int) -&gt;Void = f” would infer T = Int). We could permit explicit specialization here, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let x = f&lt;Int&gt;// x has type (Int) -&gt;Void</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Unlikely</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Features in this category have been requested at various times, but they don’t fit well with Swift’s generics system because they cause some part of the model to become overly complicated, have unacceptable implementation limitations, or overlap significantly with existing features.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Generic protocols</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; One of the most commonly requested features is the ability to parameterize protocols themselves. For example, a protocol that indicates that the Self type can be constructed from some specified type T:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol ConstructibleFromValue&lt;T&gt;{</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; init(_ value: T)</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Implicit in this feature is the ability for a given type to conform to the protocol in two different ways. A “Real” type might be constructible from both Float and Double, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; struct Real { … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension Real : ConstructibleFrom&lt;Float&gt;{</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; init(_ value: Float) { … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension Real : ConstructibleFrom&lt;Double&gt;{</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; init(_ value: Double) { … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Most of the requests for this feature actually want a different feature. They tend to use a parameterized Sequence as an example, e.g.,</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol Sequence&lt;Element&gt;{ … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo(strings: Sequence&lt;String&gt;) { /// works on any sequence containing Strings</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; // ...</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The actual requested feature here is the ability to say “Any type that conforms to Sequence whose Element type is String”, which is covered by the section on “Generalized existentials”, below.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; More importantly, modeling Sequence with generic parameters rather than associated types is tantalizing but wrong: you don’t want a type conforming to Sequence in multiple ways, or (among other things) your for..in loops stop working, and you lose the ability to dynamically cast down to an existential “Sequence” without binding the Element type (again, see “Generalized existentials”). Use cases similar to the ConstructibleFromValue protocol above seem too few to justify the potential for confusion between associated types and generic parameters of protocols; we’re better off not having the latter.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Private conformances</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Right now, a protocol conformance can be no less visible than the minimum of the conforming type’s access and the protocol’s access. Therefore, a public type conforming to a public protocol must provide the conformance publicly. One could imagine removing that restriction, so that one could introduce a private conformance:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public protocol P { }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; public struct X { }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension X : internal P { … } // X conforms to P, but only within this module</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The main problem with private conformances is the interaction with dynamic casting. If I have this code:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo(value: Any) {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if let x = value as? P { print(“P”) }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; foo(X())</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Under what circumstances should it print “P”? If foo() is defined within the same module as the conformance of X to P? If the call is defined within the same module as the conformance of X to P? Never? Either of the first two answers requires significant complications in the dynamic casting infrastructure to take into account the module in which a particular dynamic cast occurred (the first option) or where an existential was formed (the second option), while the third answer breaks the link between the static and dynamic type systems—none of which is an acceptable result.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Conditional conformances via protocol extensions</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; We often get requests to make a protocol conform to another protocol. This is, effectively, the expansion of the notion of “Conditional conformances” to protocol extensions. For example:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol P {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol Q {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func bar()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; extension Q : P { // every type that conforms to Q also conforms to P</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func foo() { // implement “foo” requirement in terms of “bar&quot;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; bar()</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func f&lt;T: P&gt;(t: T) { … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; struct X : Q {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func bar() { … }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; f(X()) // okay: X conforms to P through the conformance of Q to P</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; This is an extremely powerful feature: is allows one to map the abstractions of one domain into another domain (e.g., every Matrix is a Graph). However, similar to private conformances, it puts a major burden on the dynamic-casting runtime to chase down arbitrarily long and potentially cyclic chains of conformances, which makes efficient implementation nearly impossible.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Potential removals</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The generics system doesn’t seem like a good candidate for a reduction in scope; most of its features do get used fairly pervasively in the standard library, and few feel overly anachronistic. However...</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Associated type inference</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Associated type inference is the process by which we infer the type bindings for associated types from other requirements. For example:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol IteratorProtocol {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype Element</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; mutating func next() -&gt;Element?</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; struct IntIterator : IteratorProtocol {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; mutating func next() -&gt;Int? { … } // use this to infer Element = Int</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Associated type inference is a useful feature. It’s used throughout the standard library, and it helps keep associated types less visible to types that simply want to conform to a protocol. On the other hand, associated type inference is the only place in Swift where we have a global type inference problem: it has historically been a major source of bugs, and implementing it fully and correctly requires a drastically different architecture to the type checker. Is the value of this feature worth keeping global type inference in the Swift language, when we have deliberatively avoided global type inference elsewhere in the language?</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Existentials</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Existentials aren’t really generics per se, but the two systems are closely intertwined due to their mutable dependence on protocols.</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; *Generalized existentials</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The restrictions on existential types came from an implementation limitation, but it is reasonable to allow a value of protocol type even when the protocol has Self constraints or associated types. For example, consider IteratorProtocol again and how it could be used as an existential:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol IteratorProtocol {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; associatedtype Element</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; mutating func next() -&gt;Element?</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let it: IteratorProtocol = …</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; it.next() // if this is permitted, it could return an “Any?”, i.e., the existential that wraps the actual element</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Additionally, it is reasonable to want to constrain the associated types of an existential, e.g., “a Sequence whose element type is String” could be expressed by putting a where clause into “protocol&lt;…&gt;” or “Any&lt;…&gt;” (per “Renaming protocol&lt;…&gt;to Any&lt;…&gt;”):</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let strings: Any&lt;Sequence where .Iterator.Element == String&gt;= [“a”, “b”, “c”]</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; The leading “.” indicates that we’re talking about the dynamic type, i.e., the “Self” type that’s conforming to the Sequence protocol. There’s no reason why we cannot support arbitrary “where” clauses within the “Any&lt;…&gt;”. This very-general syntax is a bit unwieldy, but common cases can easily be wrapped up in a generic typealias (see the section “Generic typealiases” above):</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; typealias AnySequence&lt;Element&gt;= Any&lt;Sequence where .Iterator.Element == Element&gt;</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let strings: AnySequence&lt;String&gt;= [“a”, “b”, “c”]</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Opening existentials</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Generalized existentials as described above will still have trouble with protocol requirements that involve Self or associated types in function parameters. For example, let’s try to use Equatable as an existential:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; protocol Equatable {</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func ==(lhs: Self, rhs: Self) -&gt;Bool</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; func !=(lhs: Self, rhs: Self) -&gt;Bool</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let e1: Equatable = …</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; let e2: Equatable = …</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if e1 == e2 { … } // error: e1 and e2 don’t necessarily have the same dynamic type</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; One explicit way to allow such operations in a type-safe manner is to introduce an “open existential” operation of some sort, which extracts and gives a name to the dynamic type stored inside an existential. For example:</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if let storedInE1 = e1 openas T { // T is a the type of storedInE1, a copy of the value stored in e1</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if let storedInE2 = e2 as? T { // is e2 also a T?</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; if storedInE1 == storedInE2 { … } // okay: storedInT1 and storedInE2 are both of type T, which we know is Equatable</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; }</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; Thoughts?</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; - Doug</div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt; </div><div style="color:rgb(0,0,0);font-family:calibri,sans-serif;font-size:14px">&gt;</div></div></div></div>