<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="">Am 25.05.2016 um 19:13 schrieb Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>>:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><br class="">Sent from my iPad</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">On May 25, 2016, at 11:18 AM, Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class=""></div><div class="">Just realized that Matthew did introduce `sealed` exactly to enable this for public types. That's fine with me!</div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">Yeah, and it doesn't require repeating the subclass all in one place which I think is a better fit for Swift.</span></div></blockquote><div><br class=""></div>On the other hand I like that I can see at a glance which subclasses belong to the `sealed` class.</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I'm thinking the "exact type" cast (not in my original post) should also be a part of the solution. What do you think of that?<br class=""></div></div></blockquote><div><br class=""></div>What do you mean by "exact type“ cast?</div><div><br class=""></div><div>-Thorsten</div><div><br class=""></div><div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><br class=""><blockquote type="cite" class=""><div class=""><div class=""><br class=""></div><div class="">-Thorsten </div><div class=""><br class="">Am 25.05.2016 um 18:11 schrieb Thorsten Seitz via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""></div><div class="">Ceylon uses the following syntax for stating that a class has a finite set of subclasses:</div><div class=""><br class=""></div><div class="">class C of C1 | C2 {...}</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">-Thorsten </div><div class=""><br class="">Am 25.05.2016 um 04:01 schrieb David Sweeris via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">Or if there was a way to declare that a class/protocol can only have a defined set of subclasses/conforming types.<br class=""><br class="">Sent from my iPhone</div><div class=""><br class="">On May 24, 2016, at 15:35, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div dir="ltr" class="">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 class=""><br class=""></div><div class="">Austin</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Tue, May 24, 2016 at 1:29 PM, Leonardo Pessoa<span class="Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:me@lmpessoa.com" target="_blank" class="">me@lmpessoa.com</a>></span><span class="Apple-converted-space"> </span>wrote:<br class=""><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex;">I like this but I think it would be a lot hard to ensure you have all<br class="">subclasses covered. Think of frameworks that could provide many<br class="">unsealed classes. You could also have an object that would have to<br class="">handle a large subtree (NSObject?) and the order in which the cases<br class="">are evaluated would matter just as in exception handling in languages<br class="">such as Java (or require some evaluation from the compiler to raise<br class="">warnings). I'm +1 for this but these should be open-ended like strings<br class="">and require the default case.<br class=""><br class="">On 24 May 2016 at 17:08, Austin Zheng via swift-evolution<br class=""><div class="HOEnZb"><div class="h5"><<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">> I have been hoping for the exhaustive pattern matching feature for a while<br class="">> now, and would love to see a proposal.<br class="">><br class="">> Austin<br class="">><br class="">> On Tue, May 24, 2016 at 1:01 PM, Matthew Johnson via swift-evolution<br class="">> <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">>><br class="">>> Swift currently requires a default pattern matching clause when you switch<br class="">>> on an existential or a non-final class even if the protocol or class is<br class="">>> non-public and all cases are covered. It would be really nice if the<br class="">>> default clause were not necessary in this case. The compiler has the<br class="">>> necessary information to prove exhaustiveness.<br class="">>><br class="">>> Related to this is the idea of introducing something like a `sealed`<br class="">>> modifier that could be applied to public protocols and classes. The<br class="">>> protocol or class would be visible when the module is imported, but<br class="">>> conformances or subclasses outside the declaring module would be prohibited.<br class="">>> Internal and private protocols and classes would implicitly be sealed since<br class="">>> they are not visible outside the module. Any protocols that inherit from a<br class="">>> sealed protocol or classes that inherit from a sealed class would also be<br class="">>> implicitly sealed (if we didn’t do this the sealing of the superprotocol /<br class="">>> superclass could be violated by conforming to or inheriting from a<br class="">>> subprotocol / subclass).<br class="">>><br class="">>> Here are examples that I would like to see be valid:<br class="">>><br class="">>> protocol P {}<br class="">>> // alternatively public sealed protocol P {}<br class="">>> struct P1: P {}<br class="">>> struct P2: P {}<br class="">>><br class="">>> func p(p: P) -> Int {<br class="">>> switch p {<br class="">>> case is P1: return 1 // alternatively an `as` cast<br class="">>> case is P2: return 2 // alternatively an `as` cast<br class="">>> }<br class="">>> }<br class="">>><br class="">>> class C {}<br class="">>> // alternatively public sealed class C {}<br class="">>> class C1: C {}<br class="">>> class C2: C {}<br class="">>><br class="">>> func c(c: C) -> Int {<br class="">>> switch c {<br class="">>> case is C1: return 1 // alternatively an `as` cast<br class="">>> case is C2: return 2 // alternatively an `as` cast<br class="">>> case is C: return 0 // alternatively an `as` cast<br class="">>> }<br class="">>> }<br class="">>><br class="">>> I am wondering if this is something the community is interested in. If<br class="">>> so, I am wondering if this is something that might be possible in the Swift<br class="">>> 3 timeframe (maybe just for private and internal protocols and classes) or<br class="">>> if it should wait for Swift 4 (this is likely the case).<br class="">>><br class="">>> -Matthew<br class="">>> _______________________________________________<br class="">>> swift-evolution mailing list<br class="">>><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">>><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">><br class="">><br class="">><br class="">> _______________________________________________<br class="">> swift-evolution mailing list<br class="">><span class="Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">><span class="Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">><br class=""></div></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div></div></div></blockquote></div><br class=""></body></html>