> On May 25, 2016, at 1:09 PM, Xiaodi Wu <[email protected]> wrote:
>
> On Wed, May 25, 2016 at 12:49 PM, Matthew Johnson via swift-evolution
> <[email protected] <mailto:[email protected]>>wrote:
>
>
> Sent from my iPad
>
> On May 25, 2016, at 12:41 PM, Charlie Monroe <[email protected]
> <mailto:[email protected]>> 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.
>
>
> This doesn't at all solve the parent issue of switching exhaustively, but
> switching over dynamicType distinguishes subclasses from base classes quite
> adequately:
>
> ```
> class Foo { }
>
> class Bar : Foo { }
>
> class Baz : Foo { }
>
> let b = Bar()
>
> switch b.dynamicType {
> case let t where t == Foo.self:
> print("Foo!")
> case let t where t == Bar.self:
> print("Bar!")
> case let t where t == Baz.self:
> print("Baz!")
> default:
> print("Boo...")
> }
> ```
It’s good to know about this capability, but it isn’t really a solution. It
doesn’t give you a name bound to `b` with the appropriate type for the case.
`t` is bound to `Bar.self`.
>
>
>>
>>>
>>>>
>>>> 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] <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
