Sent from my iPad
> On May 24, 2016, at 9:01 PM, David Sweeris via swift-evolution > <[email protected]> wrote: > > Or if there was a way to declare that a class/protocol can only have a > defined set of subclasses/conforming types. Yes, that is why I suggest introducing 'sealed'. > > Sent from my iPhone > >> On May 24, 2016, at 15:35, Austin Zheng via swift-evolution >> <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> 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 >>> > <[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 >>> > >> >> _______________________________________________ >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
