[swift-evolution] [Pitch] consistent public access modifiers

[Matthew Johnson]

> On Feb 16, 2017, at 8:21 AM, James Froggatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On 16 Feb 2017, at 02:13, Jordan Rose <jordan_rose at apple.com> wrote:
>> 
>> 
>>> On Feb 13, 2017, at 09:28, James Froggatt via swift-evolution <swift-evolution at 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…

This could be facilitated by the proposal I put forward that started this thread.  The idea is to put enums, classes and protocols on more equal footing.  I used the term `closed` in the sense that it is typically used for enums, but also allow it to be used with classes and protocols which may be exhaustively switched over.  I used `public` in the sense that we say “resilient enum”, `public class` or “non-open” protocol.  Finally, I expanded the use of `open` to also be applicable to protocols and user-extensible enums.

It will probably be more clear after I share my manifesto on value subtyping (coming very soon), but the perspective underlying this idea is that we have three different kinds of types which may have concrete subtypes: enums (enhanced as I will demonstrate in my value subtyping manifesto), classes and protocols.  With this in mind, it seems wise (to me at least) to establish common syntax and semantics for controlling how new concrete subtypes may be introduced (by users of a module, by future versions of the module, etc).

> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution