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

[Austin Zheng]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160524/ca02a97b/attachment.html>