[swift-evolution] [Pitch] Exhaustive pattern matching for protocols and classes

Matthew Johnson matthew at anandabits.com
Thu May 26 08:12:42 CDT 2016 


Sent from my iPad

> On May 26, 2016, at 8:06 AM, Thorsten Seitz <tseitz42 at icloud.com> wrote:
> 
> 
>> Am 25.05.2016 um 19:13 schrieb Matthew Johnson <matthew at anandabits.com>:
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On May 25, 2016, at 11:18 AM, Thorsten Seitz via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> Just realized that Matthew did introduce `sealed` exactly to enable this for public types. That's fine with me!
>> 
>> Yeah, and it doesn't require repeating the subclass all in one place which I think is a better fit for Swift.
> 
> On the other hand I like that I can see at a glance which subclasses belong to the `sealed` class.

Yeah, the value of this is the documents on value.  The question is whether maintaining it is worth the effort, especially when tools could provide the same information.  Reasonable people can disagree on this.  I don't feel too strongly about it, but lean slightly towards not requiring the explicit list.  

> 
> 
>> 
>> I'm thinking the "exact type" cast (not in my original post) should also be a part of the solution.  What do you think of that?
> 
> What do you mean by "exact type“ cast?

I mean a cast operator where a subclass will not match a cast to any of its ancestor types.  That would let you be sure to provide a case for each individual type and ensure the correct case is selected regardless of order.  It can be done today but is verbose and error prone:

case let dog as Dog where dog.dynamicType == Dog.self:

> 
> -Thorsten
> 
> 
>> 
>>> 
>>> -Thorsten 
>>> 
>>>> Am 25.05.2016 um 18:11 schrieb Thorsten Seitz via swift-evolution <swift-evolution at swift.org>:
>>>> 
>>>> 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 <swift-evolution at swift.org>:
>>>>> 
>>>>> 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 at 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 <me at 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 at 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 at 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 at swift.org
>>>>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > swift-evolution mailing list
>>>>>>> > swift-evolution at swift.org
>>>>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>>>> >
>>>>>> 
>>>>>> _______________________________________________
>>>>>> swift-evolution mailing list
>>>>>> swift-evolution at swift.org
>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>> _______________________________________________
>>>>> swift-evolution mailing list
>>>>> swift-evolution at swift.org
>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160526/321f89ef/attachment.html>

More information about the swift-evolution mailing list