> 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...
>
>>
>> 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
>>>>> <[email protected] <mailto:[email protected]>> 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 <mailto:[email protected]>
>>>>> Sent: 24/05/2016 11:01 PM
>>>>> To: Austin Zheng <mailto:[email protected]>
>>>>> Cc: Leonardo Pessoa <mailto:[email protected]>; swift-evolution
>>>>> <mailto:[email protected]>
>>>>> 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
>>>>> <[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]
https://lists.swift.org/mailman/listinfo/swift-evolution
