> On May 25, 2016, at 1:09 PM, Charlie Monroe <[email protected]> wrote:
>
>> 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.
>
> You use case instace.dynamicType == Dog.self. It's a bit more verbose, but
> makes sure that the exact type is matched.
It could replace the `is` cast, but not the `as` cast where we get a name with
the correct type bound to the value. If we’re going to introduce `asExactly`
we might as well also introduce `isExactly` for consistency and convenience.
>
> I really wish, though for Xcode to feature something like the HHEnumeration
> plugin does - as soon as you type switch <variable>, it will create all the
> case statements. And with sealed classes, it could ensure the correct order
> so that some case isn't shadowed by the other. But that's kind of off topic.
>
>>
>>>
>>>>
>>>>>
>>>>> 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
