> On 16 Feb 2017, at 02:13, Jordan Rose <jordan_r...@apple.com> wrote: > > >> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> Having loosely followed this discussion, the way I'm thinking of ‘closed’ is >> as a modifier which would let you switch over something from outside the >> module in which it is declared. >> >> From outside the declaring module: >> • A closed enum's cases can be exhaustively switched. >> • A closed protocol's conforming types can be exhaustively switched. >> • A closed class's subclasses can be exhaustively switched. >> >> If this is correct, I can't help but think ‘closed’ is describing something >> subtly different in each case - picking and choosing the ‘important’ >> relationship for each type, while protocols already have a subtyping >> relationship, and it sounds like there's possibility for enum subtyping in >> the future. >> >> I'd rather keep ‘open’ (and a potential future ‘closed’) purely describing >> the subtyping relationship, and have some other means of labelling >> conformance and cases as switchable. > > This is definitely not correct. A "closed" enum's cases can be exhaustively > switched from any module, but a non-open protocol's conforming types or > non-open class's subclasses cannot be exhaustively switched from anywhere > except the defining module (because there may be internal subclasses). > > Jordan
Thanks for the correction, I hadn't considered that. Switching over subclasses/conformances could be quite a useful feature in itself, and with the way things are going it would likely need yet another access level… _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
