[Pitch] Exhaustive pattern matching for protocols and classes


(Leonardo Pessoa) #1

Sent from my iPad

I like the idea of sealed types but I think much better is Ceylon's
concept of previously declaring the many subclasses that are going to exist
both because I can have a bunch of public classes in a framework and
restrict their subclasses and because there are threads in this group
discussing the idea of a union type (perhaps both ideas could benefit from
one another).

I think there are reasonable arguments both for and against forcing the
programmer to declare all subclasses in one location. The argument for it
is that it provides documentation value by listing all possible cases in
the same place. The argument against it is that this could get annoying as
you add subclasses inside the module and the compiler will tell you when
you miss a case in your switches anyway.

Actually this "annoyance" is a good part as any other warning you get from
the compiler in any situations to tell you something is wrong in your code
and needs fixing.

···

On Wednesday, 25 May 2016, Matthew Johnson <matthew@anandabits.com> wrote:

On May 25, 2016, at 12:04 PM, Leonardo Pessoa via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote:

Another idea could be to add a single simple keyword to the root class
(could even be sealed but I don't think it grabs this concept) to declare
all its subclasses must exist within the same module. That would restrict
the number of subclasses to the compiler without requiring us to revisit
the root class each time we need to create a subclass and would still allow
for every subclass to be public.

Sealed wouldn't be a good idea because the root class would still enable
subclassing and it would be ideal that the switch could only work with
these "sealed" types.

I proposed 'sealed' for this using the definition we have seen previously
on the list - closed to inheritance outside the module. It doesn't mean
'final'.

+1 for enabling this for protocols too.

Just a few issues:
- here we're considering having subclasses of subclasses, or not?

Yes, as long as they're within the same module as the 'sealed' type.

-what about public protocols being adopted outside the module, should we
just ignore them or completely forbid the adoption?

The ability to have 'public sealed' is the only reason to have 'sealed' at
all. 'private' and 'internal' are implicitly 'sealed' by lack of external
visibility. If your users need to be able to conform to your protocol you
wouldn't be able to make it 'sealed' and would have to include the default
clause in a switch statement. 'sealed' is for times where your design
requires a fixed set of conformances that are all packed together in the
same module as the protocol, but the protocol must be visible publicly.

------------------------------
From: Thorsten Seitz via swift-evolution
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
Sent: ‎25/‎05/‎2016 01:18 PM
To: Thorsten Seitz <javascript:_e(%7B%7D,'cvml','tseitz42@icloud.com');>
Cc: swift-evolution
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
Subject: Re: [swift-evolution] [Pitch] Exhaustive pattern matching
forprotocols and classes

Just realized that Matthew did introduce `sealed` exactly to enable this
for public types. That's fine with me!

-Thorsten

Am 25.05.2016 um 18:11 schrieb Thorsten Seitz via swift-evolution < > swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@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@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@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@swift.org > <javascript:_e(%7B%7D,'cvml','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 <me@lmpessoa.com > <javascript:_e(%7B%7D,'cvml','me@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 >> <javascript:_e(%7B%7D,'cvml','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 >> <javascript:_e(%7B%7D,'cvml','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
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
> https://lists.swift.org/mailman/listinfo/swift-evolution
>

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
<javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>
https://lists.swift.org/mailman/listinfo/swift-evolution

--


(Matthew Johnson) #2

Sent from my iPad

I like the idea of sealed types but I think much better is Ceylon's concept of previously declaring the many subclasses that are going to exist both because I can have a bunch of public classes in a framework and restrict their subclasses and because there are threads in this group discussing the idea of a union type (perhaps both ideas could benefit from one another).

I think there are reasonable arguments both for and against forcing the programmer to declare all subclasses in one location. The argument for it is that it provides documentation value by listing all possible cases in the same place. The argument against it is that this could get annoying as you add subclasses inside the module and the compiler will tell you when you miss a case in your switches anyway.

Actually this "annoyance" is a good part as any other warning you get from the compiler in any situations to tell you something is wrong in your code and needs fixing.

You can get the warning without explicitly stating the list of classes in the same place.

···

Sent from my iPad

On May 25, 2016, at 5:52 PM, Leonardo Pessoa <me@lmpessoa.com> wrote:

On Wednesday, 25 May 2016, Matthew Johnson <matthew@anandabits.com> wrote:

On May 25, 2016, at 12:04 PM, Leonardo Pessoa via swift-evolution <swift-evolution@swift.org> wrote:

Another idea could be to add a single simple keyword to the root class (could even be sealed but I don't think it grabs this concept) to declare all its subclasses must exist within the same module. That would restrict the number of subclasses to the compiler without requiring us to revisit the root class each time we need to create a subclass and would still allow for every subclass to be public.

Sealed wouldn't be a good idea because the root class would still enable subclassing and it would be ideal that the switch could only work with these "sealed" types.

I proposed 'sealed' for this using the definition we have seen previously on the list - closed to inheritance outside the module. It doesn't mean 'final'.

+1 for enabling this for protocols too.

Just a few issues:
- here we're considering having subclasses of subclasses, or not?

Yes, as long as they're within the same module as the 'sealed' type.

-what about public protocols being adopted outside the module, should we just ignore them or completely forbid the adoption?

The ability to have 'public sealed' is the only reason to have 'sealed' at all. 'private' and 'internal' are implicitly 'sealed' by lack of external visibility. If your users need to be able to conform to your protocol you wouldn't be able to make it 'sealed' and would have to include the default clause in a switch statement. 'sealed' is for times where your design requires a fixed set of conformances that are all packed together in the same module as the protocol, but the protocol must be visible publicly.

From: Thorsten Seitz via swift-evolution
Sent: ‎25/‎05/‎2016 01:18 PM
To: Thorsten Seitz
Cc: swift-evolution
Subject: Re: [swift-evolution] [Pitch] Exhaustive pattern matching forprotocols and classes

Just realized that Matthew did introduce `sealed` exactly to enable this for public types. That's fine with me!

-Thorsten

Am 25.05.2016 um 18:11 schrieb Thorsten Seitz via swift-evolution <swift-evolution@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@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@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@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

--