Just realized that Matthew did introduce `sealed` exactly to enable this for public types. That's fine with me!
-Thorsten > Am 25.05.2016 um 18:11 schrieb Thorsten Seitz via swift-evolution > <swift-evolution@swift.org>: > > 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@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@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 <m...@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@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@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@swift.org >>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> > >>>> > >>>> > >>>> > _______________________________________________ >>>> > swift-evolution mailing list >>>> > swift-evolution@swift.org >>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>> > >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution