[swift-evolution] [Pitch] Exhaustive pattern matching for protocols and classes

[Thorsten Seitz]

Ceylon uses the following syntax for stating that a class has a finite set of subclasses:

class C of C1 | C2 {...}

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.

-Thorsten 

> Am 25.05.2016 um 04:01 schrieb David Sweeris via swift-evolution <swift-evolution at swift.org>:
> 
> Or if there was a way to declare that a class/protocol can only have a defined set of subclasses/conforming types.
> 
> Sent from my iPhone
> 
>> On May 24, 2016, at 15:35, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 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.
>> 
>> Austin
>> 
>>> On Tue, May 24, 2016 at 1:29 PM, Leonardo Pessoa <me at lmpessoa.com> wrote:
>>> I like this but I think it would be a lot hard to ensure you have all
>>> subclasses covered. Think of frameworks that could provide many
>>> unsealed classes. You could also have an object that would have to
>>> handle a large subtree (NSObject?) and the order in which the cases
>>> are evaluated would matter just as in exception handling in languages
>>> such as Java (or require some evaluation from the compiler to raise
>>> warnings). I'm +1 for this but these should be open-ended like strings
>>> and require the default case.
>>> 
>>> On 24 May 2016 at 17:08, Austin Zheng via swift-evolution
>>> <swift-evolution at swift.org> wrote:
>>> > I have been hoping for the exhaustive pattern matching feature for a while
>>> > now, and would love to see a proposal.
>>> >
>>> > Austin
>>> >
>>> > On Tue, May 24, 2016 at 1:01 PM, Matthew Johnson via swift-evolution
>>> > <swift-evolution at swift.org> wrote:
>>> >>
>>> >> Swift currently requires a default pattern matching clause when you switch
>>> >> on an existential or a non-final class even if the protocol or class is
>>> >> non-public and all cases are covered.  It would be really nice if the
>>> >> default clause were not necessary in this case.  The compiler has the
>>> >> necessary information to prove exhaustiveness.
>>> >>
>>> >> Related to this is the idea of introducing something like a `sealed`
>>> >> modifier that could be applied to public protocols and classes.  The
>>> >> protocol or class would be visible when the module is imported, but
>>> >> conformances or subclasses outside the declaring module would be prohibited.
>>> >> Internal and private protocols and classes would implicitly be sealed since
>>> >> they are not visible outside the module.  Any protocols that inherit from a
>>> >> sealed protocol or classes that inherit from a sealed class would also be
>>> >> implicitly sealed (if we didn’t do this the sealing of the superprotocol /
>>> >> superclass could be violated by conforming to or inheriting from a
>>> >> subprotocol / subclass).
>>> >>
>>> >> Here are examples that I would like to see be valid:
>>> >>
>>> >> protocol P {}
>>> >> // alternatively public sealed protocol P {}
>>> >> struct P1: P {}
>>> >> struct P2: P {}
>>> >>
>>> >> func p(p: P) -> Int {
>>> >>     switch p {
>>> >>     case is P1: return 1 // alternatively an `as` cast
>>> >>     case is P2: return 2 // alternatively an `as` cast
>>> >>     }
>>> >> }
>>> >>
>>> >> class C {}
>>> >> // alternatively public sealed class C {}
>>> >> class C1: C {}
>>> >> class C2: C {}
>>> >>
>>> >> func c(c: C) -> Int {
>>> >>     switch c {
>>> >>     case is C1: return 1 // alternatively an `as` cast
>>> >>     case is C2: return 2 // alternatively an `as` cast
>>> >>     case is C: return 0   // alternatively an `as` cast
>>> >>     }
>>> >> }
>>> >>
>>> >> I am wondering if this is something the community is interested in.  If
>>> >> so, I am wondering if this is something that might be possible in the Swift
>>> >> 3 timeframe (maybe just for private and internal protocols and classes) or
>>> >> if it should wait for Swift 4 (this is likely the case).
>>> >>
>>> >> -Matthew
>>> >> _______________________________________________
>>> >> swift-evolution mailing list
>>> >> swift-evolution at swift.org
>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > swift-evolution mailing list
>>> > swift-evolution at swift.org
>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>> >
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160525/3dcd16a8/attachment.html>