Sent from my iPad
> On May 26, 2016, at 8:25 AM, Thorsten Seitz <tseit...@icloud.com> wrote: > > Ceylon requires checks whether cases are disjoint, i.e. when one case > contains a superclass of another case then this will be a type error „cases > are not disjoint“. > > FWIW: Ceylon requires classes with enumerated subclasses to be abstract. Interesting, thanks for mentioning this. The abstract requirement is what makes disjointedness at least partly possible (what if a subclass has further descendants though?). But it still only works for a single level of inheritance: sealed abstract class A {} class B : A {} class C : A {} class D : B {} class E : B {} With a disjoint requirement I cannot ever match D and E because that would not be exhaustive and I am prohibited from matching them along side B which would be exhaustive but isn't disjoint. I don't think that solution is appropriate to Swift. > > -Thorsten > > >> Am 25.05.2016 um 19:49 schrieb Matthew Johnson via swift-evolution >> <swift-evolution@swift.org>: >> >> >> >> Sent from my iPad >> >>> On May 25, 2016, at 12:41 PM, Charlie Monroe <char...@charliemonroe.net> >>> wrote: >>> >>>> Got it. You could also say it is safer because you can't have a supertype >>>> case "swallow" a subtype value accidentally. An "exact type" cast would >>>> prevent this possibility. >>> >>> This still can be an issue since you still need to do the switch in >>> init(instance:), but it's just one place within the entire module, so it >>> can be more easily managed... >> >> Yes, agree. That's why your enum is safer. I think we do need an exact >> type cast to prevent this problem. 'isExaclty' and 'asExactly' seem are a >> bit verbose but are very clear. I can't think of anything I like that is >> more concise. >> >>> >>>> >>>>> >>>>> enum AnimalSubclasses { >>>>> >>>>> case Dog >>>>> case Cat >>>>> >>>>> init(instance: Animal) { >>>>> switch instance { >>>>> case is Dog: self = .Dog >>>>> case is Cat: self = .Cat >>>>> default: fatalError("Unhandled instance \(instance)!") >>>>> } >>>>> >>>>> } >>>>> >>>>>> One thing I have considered that might also be worth introducing is an >>>>>> exact match cast. This would prevent the possibility of putting a >>>>>> superclass case first and having it “steal” subclasses which were >>>>>> intended to be covered by a case later in the switch. If we introduce >>>>>> exact match you would be able to write a switch that must always cover >>>>>> every concrete type, including all subclasses. >>>>>> >>>>>>> >>>>>>> Charlie >>>>>>> >>>>>>> >>>>>>>> On May 25, 2016, at 4:41 AM, Leonardo Pessoa via swift-evolution >>>>>>>> <swift-evolution@swift.org> wrote: >>>>>>>> >>>>>>>> Limiting the amount of subclasses is not really a good idea as you >>>>>>>> would need to introduce another mechanism in the language while the >>>>>>>> proposed feature requires much less. And you're thinking only about >>>>>>>> the restrictive set (internal and private) and forgetting the more >>>>>>>> open end (public). Why is it so bad for this proposal to support >>>>>>>> requiring the default case? If its possible for the compiler to >>>>>>>> discover you covered all possible cases it would be fine not having >>>>>>>> default but IMHO in most cases it will find out there are more not >>>>>>>> explicitly covered. >>>>>>>> From: David Sweeris >>>>>>>> Sent: 24/05/2016 11:01 PM >>>>>>>> To: Austin Zheng >>>>>>>> Cc: Leonardo Pessoa; swift-evolution >>>>>>>> Subject: Re: [swift-evolution] [Pitch] Exhaustive pattern matching >>>>>>>> forprotocols and classes >>>>>>>> >>>>>>>> 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 >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution