<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div></div><div>Just realized that Matthew did introduce `sealed` exactly to enable this for public types. That's fine with me!</div><div><br></div><div>-Thorsten </div><div><br>Am 25.05.2016 um 18:11 schrieb Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>Ceylon uses the following syntax for stating that a class has a finite set of subclasses:</div><div><br></div><div>class C of C1 | C2 {...}</div><div><br></div><div>where `|` is the type union operator. Swift could use a simple comma separated list instead after the `or`. The advantage over sealed+private/internal would be thatnthe class or protocol could be public as well.</div><div><br></div><div>-Thorsten </div><div><br>Am 25.05.2016 um 04:01 schrieb David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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"><<a href="mailto:me@lmpessoa.com" target="_blank">me@lmpessoa.com</a>></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"><<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
> I have been hoping for the exhaustive pattern matching feature for a while<br>
> now, and would love to see a proposal.<br>
><br>
> Austin<br>
><br>
> On Tue, May 24, 2016 at 1:01 PM, Matthew Johnson via swift-evolution<br>
> <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br>
>><br>
>> Swift currently requires a default pattern matching clause when you switch<br>
>> on an existential or a non-final class even if the protocol or class is<br>
>> non-public and all cases are covered. It would be really nice if the<br>
>> default clause were not necessary in this case. The compiler has the<br>
>> necessary information to prove exhaustiveness.<br>
>><br>
>> Related to this is the idea of introducing something like a `sealed`<br>
>> modifier that could be applied to public protocols and classes. The<br>
>> protocol or class would be visible when the module is imported, but<br>
>> conformances or subclasses outside the declaring module would be prohibited.<br>
>> Internal and private protocols and classes would implicitly be sealed since<br>
>> they are not visible outside the module. Any protocols that inherit from a<br>
>> sealed protocol or classes that inherit from a sealed class would also be<br>
>> implicitly sealed (if we didn’t do this the sealing of the superprotocol /<br>
>> superclass could be violated by conforming to or inheriting from a<br>
>> subprotocol / subclass).<br>
>><br>
>> Here are examples that I would like to see be valid:<br>
>><br>
>> protocol P {}<br>
>> // alternatively public sealed protocol P {}<br>
>> struct P1: P {}<br>
>> struct P2: P {}<br>
>><br>
>> func p(p: P) -> Int {<br>
>> switch p {<br>
>> case is P1: return 1 // alternatively an `as` cast<br>
>> case is P2: return 2 // alternatively an `as` cast<br>
>> }<br>
>> }<br>
>><br>
>> class C {}<br>
>> // alternatively public sealed class C {}<br>
>> class C1: C {}<br>
>> class C2: C {}<br>
>><br>
>> func c(c: C) -> Int {<br>
>> switch c {<br>
>> case is C1: return 1 // alternatively an `as` cast<br>
>> case is C2: return 2 // alternatively an `as` cast<br>
>> case is C: return 0 // alternatively an `as` cast<br>
>> }<br>
>> }<br>
>><br>
>> I am wondering if this is something the community is interested in. If<br>
>> so, I am wondering if this is something that might be possible in the Swift<br>
>> 3 timeframe (maybe just for private and internal protocols and classes) or<br>
>> if it should wait for Swift 4 (this is likely the case).<br>
>><br>
>> -Matthew<br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><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></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></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>