<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>Or if there was a way to declare that a class/protocol can only have a defined set of subclasses/conforming types.<br><br>Sent from my iPhone</div><div><br>On May 24, 2016, at 15:35, Austin Zheng via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">If you pattern match on a type that is declared internal or private, it is impossible for the compiler to not have an exhaustive list of subclasses that it can check against.<div><br></div><div>Austin</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 24, 2016 at 1:29 PM, Leonardo Pessoa <span dir="ltr">&lt;<a href="mailto:me@lmpessoa.com" target="_blank">me@lmpessoa.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I like this but I think it would be a lot hard to ensure you have all<br>
subclasses covered. Think of frameworks that could provide many<br>
unsealed classes. You could also have an object that would have to<br>
handle a large subtree (NSObject?) and the order in which the cases<br>
are evaluated would matter just as in exception handling in languages<br>
such as Java (or require some evaluation from the compiler to raise<br>
warnings). I'm +1 for this but these should be open-ended like strings<br>
and require the default case.<br>
<br>
On 24 May 2016 at 17:08, Austin Zheng via swift-evolution<br>
<div class="HOEnZb"><div class="h5">&lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt; I have been hoping for the exhaustive pattern matching feature for a while<br>
&gt; now, and would love to see a proposal.<br>
&gt;<br>
&gt; Austin<br>
&gt;<br>
&gt; On Tue, May 24, 2016 at 1:01 PM, Matthew Johnson via swift-evolution<br>
&gt; &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Swift currently requires a default pattern matching clause when you switch<br>
&gt;&gt; on an existential or a non-final class even if the protocol or class is<br>
&gt;&gt; non-public and all cases are covered.&nbsp; It would be really nice if the<br>
&gt;&gt; default clause were not necessary in this case.&nbsp; The compiler has the<br>
&gt;&gt; necessary information to prove exhaustiveness.<br>
&gt;&gt;<br>
&gt;&gt; Related to this is the idea of introducing something like a `sealed`<br>
&gt;&gt; modifier that could be applied to public protocols and classes.&nbsp; The<br>
&gt;&gt; protocol or class would be visible when the module is imported, but<br>
&gt;&gt; conformances or subclasses outside the declaring module would be prohibited.<br>
&gt;&gt; Internal and private protocols and classes would implicitly be sealed since<br>
&gt;&gt; they are not visible outside the module.&nbsp; Any protocols that inherit from a<br>
&gt;&gt; sealed protocol or classes that inherit from a sealed class would also be<br>
&gt;&gt; implicitly sealed (if we didn’t do this the sealing of the superprotocol /<br>
&gt;&gt; superclass could be violated by conforming to or inheriting from a<br>
&gt;&gt; subprotocol / subclass).<br>
&gt;&gt;<br>
&gt;&gt; Here are examples that I would like to see be valid:<br>
&gt;&gt;<br>
&gt;&gt; protocol P {}<br>
&gt;&gt; // alternatively public sealed protocol P {}<br>
&gt;&gt; struct P1: P {}<br>
&gt;&gt; struct P2: P {}<br>
&gt;&gt;<br>
&gt;&gt; func p(p: P) -&gt; Int {<br>
&gt;&gt;&nbsp; &nbsp; &nbsp;switch p {<br>
&gt;&gt;&nbsp; &nbsp; &nbsp;case is P1: return 1 // alternatively an `as` cast<br>
&gt;&gt;&nbsp; &nbsp; &nbsp;case is P2: return 2 // alternatively an `as` cast<br>
&gt;&gt;&nbsp; &nbsp; &nbsp;}<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; class C {}<br>
&gt;&gt; // alternatively public sealed class C {}<br>
&gt;&gt; class C1: C {}<br>
&gt;&gt; class C2: C {}<br>
&gt;&gt;<br>
&gt;&gt; func c(c: C) -&gt; Int {<br>
&gt;&gt;&nbsp; &nbsp; &nbsp;switch c {<br>
&gt;&gt;&nbsp; &nbsp; &nbsp;case is C1: return 1 // alternatively an `as` cast<br>
&gt;&gt;&nbsp; &nbsp; &nbsp;case is C2: return 2 // alternatively an `as` cast<br>
&gt;&gt;&nbsp; &nbsp; &nbsp;case is C: return 0&nbsp; &nbsp;// alternatively an `as` cast<br>
&gt;&gt;&nbsp; &nbsp; &nbsp;}<br>
&gt;&gt; }<br>
&gt;&gt;<br>
&gt;&gt; I am wondering if this is something the community is interested in.&nbsp; If<br>
&gt;&gt; so, I am wondering if this is something that might be possible in the Swift<br>
&gt;&gt; 3 timeframe (maybe just for private and internal protocols and classes) or<br>
&gt;&gt; if it should wait for Swift 4 (this is likely the case).<br>
&gt;&gt;<br>
&gt;&gt; -Matthew<br>
&gt;&gt; _______________________________________________<br>
&gt;&gt; swift-evolution mailing list<br>
&gt;&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; swift-evolution mailing list<br>
&gt; <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
&gt;<br>
</div></div></blockquote></div><br></div>
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>