> Am 25.05.2016 um 19:38 schrieb Matthew Johnson <[email protected]>: > > > > Sent from my iPad > > On May 25, 2016, at 12:04 PM, Leonardo Pessoa via swift-evolution > <[email protected] <mailto:[email protected]>> 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 forgot to mention this in my last reply. What I am proposing allows sealed > classes to be viewed as similar to nominal sum types. This is like Scala's > case classes. > > Ceylon's unions are structural sum types (the sum type analogue of a Tuple, > which is a structural product type). I really want to see these as well (I > recently ran into a use case where they are far superior to what we can do > today). But they are not the same as sealed classes and protocols.
That’s true and readily demonstrated by Ceylon which has both :-) -Thorsten > >> >> 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. >> >> +1 for enabling this for protocols too. >> >> Just a few issues: >> - here we're considering having subclasses of subclasses, or not? >> -what about public protocols being adopted outside the module, should we >> just ignore them or completely forbid the adoption? >> >> From: Thorsten Seitz via swift-evolution <mailto:[email protected]> >> Sent: 25/05/2016 01:18 PM >> To: Thorsten Seitz <mailto:[email protected]> >> Cc: swift-evolution <mailto:[email protected]> >> 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 >> <[email protected] <mailto:[email protected]>>: >> >>> 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 >>> <[email protected] <mailto:[email protected]>>: >>> >>>> 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 >>>> <[email protected] <mailto:[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] >>>>> <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]> >>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> > >>>>> > >>>>> > >>>>> > _______________________________________________ >>>>> > swift-evolution mailing list >>>>> > [email protected] <mailto:[email protected]> >>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> > >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
