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 < [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
