Sent from my iPad
> On May 25, 2016, at 11:18 AM, Thorsten Seitz via swift-evolution
> <swift-evolution@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.
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?
>
> -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 <m...@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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
