<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 29, 2017, at 4:48 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Sun, Jan 29, 2017 at 4:19 PM, Matthew Johnson via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2017, at 4:01 PM, David Hart <<a href="mailto:david@hartbit.com" target="_blank" class="">david@hartbit.com</a>> wrote:</div><br class="m_-8199900898737875921Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class=""><div class="">Hi Matthew,</div><div class=""><br class=""></div><div class="">I’ll reply to this post, because it allows me to discuss a few of the points in the discussion, but I’ve read the whole discussion.</div><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 29 Jan 2017, at 18:30, Matthew Johnson <<a href="mailto:matthew@anandabits.com" target="_blank" class="">matthew@anandabits.com</a>> wrote:</div><br class="m_-8199900898737875921Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class="">Hi David,<div class=""><br class=""></div><div class="">This looks like a great start.</div><div class=""><br class=""></div><div class="">One thing we should consider is whether we tie this proposal so tightly to classes or whether it might be better to call these supertype constraints. The feature might also be useful for value types if / when Swift gets value subtyping.</div></div></div></blockquote><div class=""><br class=""></div><div class="">This makes sense, especially with the Substring : String discussions going on. When I rework the proposal, I’ll try to make it more general.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">One enhancement that might be worth considering. Specifically, allowing protocols to declare a specific supertype requirement in the place where a `class` constraint would usually be found. After this proposal we could already do something similar using a `class` constraint to define a protocol and a typealias to bind it to the supertype requirement. It seems like allowing users to state this more directly would be a good idea.</div></div></div></blockquote><div class=""><br class=""></div><div class="">You lost me there. Can you give examples?</div></div></div></div></blockquote><div class=""><br class=""></div></span><div class="">Sure. In an iOS app you might want to create a protocol that should only be conformed to by `UIViewController` subclasses:</div><div class=""><br class=""></div><div class="">protocol TrackedViewController: UIViewController {</div><div class=""> var analyticsTitle: String { get }</div><div class="">}</div><div class=""><br class=""></div><div class="">This is roughly equivalent to under your proposal:</div><div class=""><br class=""></div><div class=""><div class="">protocol TrackedObject: class {</div><div class=""> var analyticsTitle: String { get }</div><div class="">}</div><div class="">typealias TrackedViewController = UIViewController & TrackedObject</div><div class=""><br class=""></div><div class="">But in this case we would be able to avoid the TrackedObject protocol which we didn’t care about or want, but were required to create in the process of creating our typealias.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Since we allow only one subclass, this gets a little tricky, right? If TrackedViewController refines UIViewController, then should it count as a subclass requirement when it comes to further composition and be required first?</div></div></div></div></div></blockquote><div><br class=""></div><div>It would be treated the same as the typealias as far as the syntax of composing existential types with `&` is concerned. I imagine the sensible thing, if we have the “class comes first requirement" is:</div><div><br class=""></div><div>protocol P {}</div><div>typealias Foo = TrackedViewController & P // allowed</div><div>typealias Foo = P & TrackedViewController // not allowed</div><div><br class=""></div><div>class MyViewController: UIVIewController, TrackedViewController {}</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">The syntax also implies that everything on UIViewController is a requirement for a TrackedViewController. Would a class that conforms to TrackedViewController automatically be a subclass of UIViewController, or would only subclasses of UIViewController be allowed to conform to TrackedViewController (i.e. is _being_ a UIViewController a requirement for conforming to TrackedViewController)? The former seems surprising, at least to me. Yet in the latter case, this would behave very differently from protocols you put on the right side of the colon. </div></div></div></div></div></blockquote><div><br class=""></div><div>I hadn’t considered this and it’s a good question. Conforming classes should still have to declare their immediate superclass. What it adds is a requirement that conforming types *eventually* have the constraining type as a supertype. A class can pick up implementation of other requirements from it’s superclass so why shouldn’t it’s superclass also be able to meet a supertype requirement.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">Would it make sense to allow a protocol to refine a struct, too?</div></div></div></div></div></blockquote><div><br class=""></div><div>Eventually, yes. Immediately, maybe. I think this makes sense as soon as we get value subtyping and / or we adopt the intersection types view and allow uninhabited existentials. Until then we probably don’t gain anything from it. </div><div><br class=""></div><div>Adding it immediately would reduce the need to make a future change and / or remember to add it when we add the other features and it probably wouldn’t cause any significant issues for users. On the other hand, it’s easy to make a case that adding it now is unnecessary and speculative complexity and we should wait until we have a real use for it.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><div class="">IMO this idea might be best considered separately. Could be nice to have, but it touches on a little more than existentials.</div></div></div></div></div></blockquote><div><br class=""></div><div>Are we going to be allowed to use these existential types as generic constraints? That was allowed in Austin’s proposal. If we are going to support this it makes sense to me that we should have support for supertype requirements in protocols. After all, what is the role of a concrete type name in the existential syntax other than to introduce what is effectively an anonymous protocol with a supertype requirement?</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><br class=""></div></div><span class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><span style="color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">As only the first element in the existential composition syntax can be a class type, and by extending this rule to typealias expansions, we can make sure that we only need to read the first element to know if it contains a class requirement.</span></div><div class=""><br class=""></div><div class="">I think this is unnecessarily limiting in a couple of ways. I agree that a class should come first if it is mentioned explicitly***. I am less sure we should require this when the type is part of a typealias combined with other protocol requirements.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I agree with Chris that I think it’s important to require the class be mentioned first when the class is mentioned explicitly. Even if we lost the Any<Base, Protocol> syntax, there is still enough similarity to a class’s inheritance/conformance clause to keep the consistency and readability.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">For example, one use case I remember discussing with Austin is refining supertype requirements. If I have a typealias which requires a superclass `Base` I should be able to form an existential using that typealias that *refines* that requirement to some type *Derived* which is a non-final subtype of `Base`. This would require syntax that allows us to put a class name in the first position, but also mention a typealias with a supertype requirement in a subsequent position.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I’ve read the examples in the thread and I think I agree that those cases should be accepted. But just to make sure we are on the same page, what does everyone think of the validity of the following cases? For shorthand, I use parentheses to represent typealias expansion. For example, when I write:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing:border-box;overflow:auto;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:16px;line-height:1.45;padding:16px;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-wrap:normal;color:rgb(51,51,51)" class=""><code class="m_-8199900898737875921language-swift" style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;line-height:inherit;padding:0px;margin:0px;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;border:0px;display:inline;word-wrap:normal"><span class="m_-8199900898737875921hljs-type" style="box-sizing:border-box;color:rgb(121,93,163)">Protocol1</span> & (<span class="m_-8199900898737875921hljs-type" style="box-sizing:border-box;color:rgb(121,93,163)">Protocol2</span> & <span class="m_-8199900898737875921hljs-type" style="box-sizing:border-box;color:rgb(121,93,163)">Protocol3</span>)</code></pre></div><div class="">I mean:</div><div class=""><br class=""></div><div class=""><pre style="box-sizing:border-box;overflow:auto;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:16px;line-height:1.45;padding:16px;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-wrap:normal;color:rgb(51,51,51)" class=""><code class="m_-8199900898737875921language-swift" style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;line-height:inherit;padding:0px;margin:0px;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal;border:0px;display:inline;word-wrap:normal"><span class="m_-8199900898737875921hljs-keyword" style="box-sizing:border-box;color:rgb(167,29,93)">typealias</span> <span class="m_-8199900898737875921hljs-type" style="box-sizing:border-box;color:rgb(121,93,163)">Something</span> = <span class="m_-8199900898737875921hljs-type" style="box-sizing:border-box;color:rgb(121,93,163)">Protocol2</span> & <span class="m_-8199900898737875921hljs-type" style="box-sizing:border-box;color:rgb(121,93,163)">Protocol3</span>
<span class="m_-8199900898737875921hljs-type" style="box-sizing:border-box;color:rgb(121,93,163)">Protocol1</span> & <span class="m_-8199900898737875921hljs-type" style="box-sizing:border-box;color:rgb(121,93,163)">Something</span></code></pre></div><div class=""><b class="">Questions</b></div><div class=""><br class=""></div><div class=""><ol style="box-sizing:border-box;padding:0px 0px 0px 2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif;font-size:16px;background-color:rgb(255,255,255)" class=""><li style="box-sizing:border-box" class="">Should class requirements be fixed to first position? I.e., should <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Protocol & Base</code> be valid and equivalent to <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Base & Protocol</code>?</li><li style="box-sizing:border-box" class="">Should repetition of class requirements in the same declaration be allowed? I.e., should <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Base & Base</code> be valid and equivalent to <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Base</code>?</li><li style="box-sizing:border-box" class="">Should repetition of class requirements through typealias expansion be allowed? I.e., should <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Base & (Base & Protocol)</code> be valid and equivalent to <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Base & Protocol</code>?</li><li style="box-sizing:border-box" class="">Should type and sub-type requirements in the same declaration be allowed? I.e., should <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Base & Derived</code> or <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Derived & Base</code> be valid and equivalent to <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Derived</code>?</li><li style="box-sizing:border-box" class="">Should type and sub-type requirements through typealias expansion be allowed? I.e., should <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Base & (Derived & Protocol)</code> or <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Derived & (Base & Protocol)</code> be valid and equivalent to <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;line-height:normal;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">Derived & Protocol</code>?</li></ol></div><div class=""><b class="">My Answers</b></div><div class=""><br class=""></div><div class=""><ol style="box-sizing:border-box;padding:0px 0px 0px 2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:'Helvetica Neue',Helvetica,'Segoe UI',Arial,freesans,sans-serif;font-size:16px;background-color:rgb(255,255,255)" class=""><li style="box-sizing:border-box" class="">No, for the reasons stated above.</li><li style="box-sizing:border-box" class="">No, because it doesn’t make sense to repeat it in the same declaration.</li><li style="box-sizing:border-box" class="">Yes, I’m gonna start agreeing with you and think will ease typealias composition.</li><li style="box-sizing:border-box" class="">No, for the same reasons as 2.</li><li style="box-sizing:border-box" class="">Yes, for the same reasons as 3.</li></ol></div></div></div></div></blockquote></span><div class="">My answer depends on whether we adopt the perspective of intersection types and allow things like `Base1 & Base2` or not. If we’re not going to do that (at least not yet) I think your answers are the right ones. </div><div class=""><br class=""></div><div class="">However, if we decide to allow uninhabiatable existentials like`Base1 & Base2` I think it would be best to just relax the rules such that they follow the logic of intersection types.</div><div class=""><br class=""></div><div class="">The good news is that (as far as I can tell) it would be an additive change to start with your rules and later adopt the intersection types approach.</div><div class=""><div class="h5"><div class=""><br class=""></div><div class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class=""><font color="#333333" face="Helvetica Neue, Helvetica, Segoe UI, Arial, freesans, sans-serif" size="3" class="">David.</font></div></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap:break-word" class=""><div class="">Matthew</div><div class=""><br class=""></div><div class="">*** One argument against requiring a class to come first is that we could conceptualize `&` as a type operator with a handful of overloads. This would include both lhs and rhs are “protocol only kinds” as well as overloads with a “protocol only kind” in either lhs or rhs and a “supertype kind” in the other position. The tricky part of pulling this off would be including an overload where both lhs and rhs have a “supertype kind”, but only when the operands have a subtype / supertype relationship with each other. </div><div class=""><br class=""></div><div class="">I suspect this conceptualization isn’t worth the complexity it brings, but it is tempting to try and view `&` as a type operator. As long as this only involves a loosening of restrictions it could probably be introduced as an additive change down the road.</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jan 29, 2017, at 10:39 AM, David Hart <<a href="mailto:david@hartbit.com" target="_blank" class="">david@hartbit.com</a>> wrote:</div><br class="m_-8199900898737875921Apple-interchange-newline"><div class=""><div style="word-wrap:break-word" class="">Hello,<div class=""><br class=""></div><div class="">As promised, I wrote the first draft of a proposal to add class requirements to the existential syntax. Please let me know what you think.</div><div class=""><br class=""></div><div class=""><a href="https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md" target="_blank" class="">https://github.com/hartbit/<wbr class="">swift-evolution/blob/subclass-<wbr class="">existentials/proposals/XXXX-<wbr class="">subclass-existentials.md</a></div><div class=""><br class=""></div><div class="">Regards,</div><div class="">David.</div><div class=""><br class=""></div><div class=""><h1 style="box-sizing:border-box;margin-right:0px;margin-bottom:16px;margin-left:0px;line-height:1.25;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';background-color:rgb(255,255,255);margin-top:0px!important" class="">Existentials for classes conforming to protocols</h1><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class=""><li style="box-sizing:border-box" class="">Proposal: <a href="https://github.com/hartbit/swift-evolution/blob/subclass-existentials/proposals/XXXX-subclass-existentials.md" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">SE-XXXX</a></li><li style="box-sizing:border-box;margin-top:0.25em" class="">Authors: <a href="http://github.com/hartbit/" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">David Hart</a>, <a href="http://github.com/austinzheng" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">Austin Zheng</a></li><li style="box-sizing:border-box;margin-top:0.25em" class="">Review Manager: TBD</li><li style="box-sizing:border-box;margin-top:0.25em" class="">Status: TBD</li></ul><h2 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;line-height:1.25;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';background-color:rgb(255,255,255)" class=""><a id="m_-8199900898737875921user-content-introduction" class="m_-8199900898737875921anchor" href="https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#introduction" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none;float:left;padding-right:4px;line-height:1" target="_blank"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Introduction</h2><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">This proposal brings more expressive power to the type system by allowing Swift to represent existentials of classes and subclasses which conform to protocols.</p><h2 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;line-height:1.25;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';background-color:rgb(255,255,255)" class=""><a id="m_-8199900898737875921user-content-motivation" class="m_-8199900898737875921anchor" href="https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#motivation" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none;float:left;padding-right:4px;line-height:1" target="_blank"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Motivation</h2><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">Currently, the only existentials which can be represented in Swift are conformances to a set of protocols, using the <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">&</code>syntax:</p><div class="m_-8199900898737875921highlight m_-8199900898737875921highlight-source-swift" style="box-sizing:border-box;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal" class=""><span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> existential<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">Hashable</span> <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">CustomStringConvertible</span></pre></div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">On the other hand, Objective-C is capable of expressing existentials of subclasses conforming to protocols with the following syntax:</p><div class="m_-8199900898737875921highlight m_-8199900898737875921highlight-source-objc" style="box-sizing:border-box;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal" class="">UIViewController<<wbr class="">UITableViewDataSource, UITableViewDelegate>* existential;</pre></div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">We propose to provide similar expressive power to Swift, which will also improve the bridging of those types from Objective-C.</p><h2 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;line-height:1.25;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';background-color:rgb(255,255,255)" class=""><a id="m_-8199900898737875921user-content-proposed-solution" class="m_-8199900898737875921anchor" href="https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#proposed-solution" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none;float:left;padding-right:4px;line-height:1" target="_blank"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Proposed solution</h2><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">The proposal keeps the existing <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">&</code> syntax but allows the first element, and only the first, to be of class type. The equivalent declaration to the above Objective-C declaration would look like this:</p><div class="m_-8199900898737875921highlight m_-8199900898737875921highlight-source-swift" style="box-sizing:border-box;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal" class=""><span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> existential<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> UIViewController <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> UITableViewDataSource <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> UITableViewDelegate</pre></div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">As in Objective-C, this existential represents classes which have <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">UIViewController</code> in their parent inheritance hierarchy and which also conform to the <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">UITableViewDataSource</code> and <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class=""><wbr class="">UITableViewDelegate</code> protocols.</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">As only the first element in the existential composition syntax can be a class type, and by extending this rule to typealias expansions, we can make sure that we only need to read the first element to know if it contains a class requirement. As a consequence, here is a list of valid and invalid code and the reasons for them:</p><div class="m_-8199900898737875921highlight m_-8199900898737875921highlight-source-swift" style="box-sizing:border-box;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal" class=""><span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> a<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">Hashable</span> <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">CustomStringConvertible</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> VALID: This is still valid, as before</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span>
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> b<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> MyObject <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">Hashable</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> VALID: This is the new rule which allows an object type in first position</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span>
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> c<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">CustomStringConvertible</span> <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> MyObject
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> INVALID: MyObject is not allowed in second position. A fix-it should help transform it to:</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> let c: MyObject & CustomStringConvertible</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span>
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">typealias</span> <span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">MyObjectStringConvertible</span> <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">=</span> MyObject <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">CustomStringConvertible</span>
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> d<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">Hashable</span> <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> MyObjectStringConvertible
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> INVALID: The typealias expansion means that the type of d expands to Hashable & MyObject & CustomStringConvertible, which has the class in the wrong position. A fix-it should help transform it to:</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> let d: MyObjectStringConvertible & Hashable</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span>
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">typealias</span> <span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">MyObjectStringConvertible</span> <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">=</span> MyObject <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">CustomStringConvertible</span>
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> e<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> MyOtherObject <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> MyObjectStringConvertible
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> INVALID: The typealias expansion would allow an existential with two class requirements, which is invalid</span></pre></div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">The following examples could technically be legal, but we believe we should keep them invalid to keep the rules simple:</p><div class="m_-8199900898737875921highlight m_-8199900898737875921highlight-source-swift" style="box-sizing:border-box;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal" class=""><span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> a<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> MyObject <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> MyObject <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">CustomStringConvertible</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> This is equivalent to MyObject & CustomStringConvertible</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span>
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> b<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> MyObjectSubclass <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> MyObject <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">Hashable</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> This is equivalent to MyObjectSubclass & Hashable</span>
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"></span>
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">typealias</span> <span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">MyObjectStringConvertible</span> <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">=</span> MyObject <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">CustomStringConvertible</span>
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> d<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> MyObject <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> MyObjectStringConvertible
<span class="m_-8199900898737875921pl-c" style="box-sizing:border-box;color:rgb(150,152,150)"><span class="m_-8199900898737875921pl-c" style="box-sizing:border-box">//</span> This is equivalent to MyObject & CustomStringConvertible</span></pre></div><h2 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;line-height:1.25;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';background-color:rgb(255,255,255)" class=""><a id="m_-8199900898737875921user-content-source-compatibility" class="m_-8199900898737875921anchor" href="https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#source-compatibility" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none;float:left;padding-right:4px;line-height:1" target="_blank"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Source compatibility</h2><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">This is a source breaking change. All types bridged from Objective-C which use the equivalent Objective-C feature import without the protocol conformances in Swift 3. This change would increase the existential's requirement and break on code which does not meet the new protocol requirements. For example, the following Objective-C code:</p><div class="m_-8199900898737875921highlight m_-8199900898737875921highlight-source-objc" style="box-sizing:border-box;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal" class=""><span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">@interface</span> <span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">MyViewController</span>
- (<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">void</span>)<span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">setup</span><span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">:</span>(nonnull UIViewController<<wbr class="">UITableViewDataSource,<wbr class="">UITableViewDelegate>*)<span class="m_-8199900898737875921pl-smi" style="box-sizing:border-box">tableVie<wbr class="">wController</span>;
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">@end</span></pre></div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">is imported into Swift 3 as:</p><div class="m_-8199900898737875921highlight m_-8199900898737875921highlight-source-swift" style="box-sizing:border-box;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal" class=""><span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">class</span> <span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">MyViewController</span> {
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">func</span> <span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">setup</span>(<span class="m_-8199900898737875921pl-smi" style="box-sizing:border-box"><span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">tableViewController</span></span>: UIViewController) {}
}</pre></div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">which allows calling the function with an invalid parameter:</p><div class="m_-8199900898737875921highlight m_-8199900898737875921highlight-source-swift" style="box-sizing:border-box;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal" class=""><span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">let</span> myViewController<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">:</span> <span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">MyViewController</span>()
myViewController.<span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">setup</span>(<span class="m_-8199900898737875921pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">UIViewC<wbr class="">ontroller</span>())</pre></div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">The previous code would have worked as long as the Objective-C code did not call any method of <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">UITableViewDataSource</code> or <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">UI<wbr class="">TableViewDelegate</code>. But if this proposal is accepted and implemented as-is, the Objective-C code would now be imported as:</p><div class="m_-8199900898737875921highlight m_-8199900898737875921highlight-source-swift" style="box-sizing:border-box;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)"><pre style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;margin-top:0px;margin-bottom:0px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;word-break:normal" class=""><span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">class</span> <span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">MyViewController</span> {
<span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">func</span> <span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">setup</span>(<span class="m_-8199900898737875921pl-smi" style="box-sizing:border-box"><span class="m_-8199900898737875921pl-en" style="box-sizing:border-box;color:rgb(121,93,163)">tableViewController</span></span>: UIViewController <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> UITableViewDataSource <span class="m_-8199900898737875921pl-k" style="box-sizing:border-box;color:rgb(167,29,93)">&</span> UITableViewDelegate) {}
}</pre></div><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">That would then cause the Swift code to fail to compile with an error which states that <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">UIViewController</code> does not conform to the <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class="">UITableViewDataSource</code> and <code style="box-sizing:border-box;font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:13.600000381469727px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px" class=""><wbr class="">UITableViewDelegate</code> protocols.</p><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">It is a source-breaking change, but should have a minimal impact for the following reasons:</p><ul style="box-sizing:border-box;padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class=""><li style="box-sizing:border-box" class="">Not many Objective-C code used the existential syntax in practice.</li><li style="box-sizing:border-box;margin-top:0.25em" class="">There generated errors are a good thing because they point out potential crashes which would have gone un-noticed.</li></ul><h2 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;line-height:1.25;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';background-color:rgb(255,255,255)" class=""><a id="m_-8199900898737875921user-content-alternatives-considered" class="m_-8199900898737875921anchor" href="https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#alternatives-considered" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none;float:left;padding-right:4px;line-height:1" target="_blank"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Alternatives considered</h2><p style="box-sizing:border-box;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255)" class="">None.</p><h2 style="box-sizing:border-box;margin-top:24px;margin-bottom:16px;line-height:1.25;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';background-color:rgb(255,255,255)" class=""><a id="m_-8199900898737875921user-content-acknowledgements" class="m_-8199900898737875921anchor" href="https://github.com/hartbit/swift-evolution/tree/subclass-existentials/proposals#acknowledgements" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none;float:left;padding-right:4px;line-height:1" target="_blank"><u class=""></u><u class=""></u><u class=""></u><u class=""></u></a>Acknowledgements</h2><div style="box-sizing:border-box;margin-top:0px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px;background-color:rgb(255,255,255);margin-bottom:0px!important" class="">Thanks to <a href="http://github.com/austinzheng" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">Austin Zheng</a> and <a href="https://github.com/anandabits" style="box-sizing:border-box;background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">Matthew Johnson</a> who brought a lot of attention to existentials in this mailing-list and from whom most of the ideas in the proposal come from.</div></div></div></div></blockquote></div><br class=""></div></div></div></blockquote></div><br class=""></div></div></blockquote></div></div></div><br class=""></div><br class="">______________________________<wbr class="">_________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class="">
<br class=""></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>