On Wednesday, 25 May 2016, Matthew Johnson <matt...@anandabits.com> wrote:
> > > Sent from my iPad > > On May 25, 2016, at 12:04 PM, Leonardo Pessoa via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote: > > I like the idea of sealed types but I think much better is Ceylon's > concept of previously declaring the many subclasses that are going to exist > both because I can have a bunch of public classes in a framework and > restrict their subclasses and because there are threads in this group > discussing the idea of a union type (perhaps both ideas could benefit from > one another). > > > I think there are reasonable arguments both for and against forcing the > programmer to declare all subclasses in one location. The argument for it > is that it provides documentation value by listing all possible cases in > the same place. The argument against it is that this could get annoying as > you add subclasses inside the module and the compiler will tell you when > you miss a case in your switches anyway. > > Actually this "annoyance" is a good part as any other warning you get from the compiler in any situations to tell you something is wrong in your code and needs fixing. > > > Another idea could be to add a single simple keyword to the root class > (could even be sealed but I don't think it grabs this concept) to declare > all its subclasses must exist within the same module. That would restrict > the number of subclasses to the compiler without requiring us to revisit > the root class each time we need to create a subclass and would still allow > for every subclass to be public. > > > Sealed wouldn't be a good idea because the root class would still enable > subclassing and it would be ideal that the switch could only work with > these "sealed" types. > > > I proposed 'sealed' for this using the definition we have seen previously > on the list - closed to inheritance outside the module. It doesn't mean > 'final'. > > > +1 for enabling this for protocols too. > > Just a few issues: > - here we're considering having subclasses of subclasses, or not? > > > Yes, as long as they're within the same module as the 'sealed' type. > > -what about public protocols being adopted outside the module, should we > just ignore them or completely forbid the adoption? > > > The ability to have 'public sealed' is the only reason to have 'sealed' at > all. 'private' and 'internal' are implicitly 'sealed' by lack of external > visibility. If your users need to be able to conform to your protocol you > wouldn't be able to make it 'sealed' and would have to include the default > clause in a switch statement. 'sealed' is for times where your design > requires a fixed set of conformances that are all packed together in the > same module as the protocol, but the protocol must be visible publicly. > > > ------------------------------ > From: Thorsten Seitz via swift-evolution > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> > Sent: 25/05/2016 01:18 PM > To: Thorsten Seitz <javascript:_e(%7B%7D,'cvml','tseit...@icloud.com');> > Cc: swift-evolution > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> > Subject: Re: [swift-evolution] [Pitch] Exhaustive pattern matching > forprotocols and classes > > 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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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 > <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> >> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> > >> > >> > _______________________________________________ >> > swift-evolution mailing list >> > swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> > >> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> > https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','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