[swift-evolution] [Proposal Draft] Remove open Access Modifier

[David Hart]

I think this proposal will receive a lot of pushback and that the use case for having a class that is subclassable inside its module but not subclassable outside the module is more frequent than you think.

> On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hi all,
> 
> Here’s a draft proposal following https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html>.
> The idea is simplify Swift’s syntax by getting rid of the `open` access modifier.
> 
> A rendered version of the proposal is available here: https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/nnnn-remove-open-access-modifier.md <https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/nnnn-remove-open-access-modifier.md>
> The raw version follows:
> 
> # Remove open Access Modifier
> 
> * Proposal: [SE-NNNN](nnnn-remove-open-access-modifier.md)
> * Author: [Dimitri Racordon](https://github.com/kyouko-taiga <https://github.com/kyouko-taiga>), Joanna Carter
> * Status: **Awaiting review**
> * Review manager: TBD
> 
> ## Introduction
> 
> Swift allows classes, methods, properties and subscripts to be marked as `final`, hence disallowing their subclassing/overriding inside **and** outside of their defining module.
> 
> It also features two access levels `open`, which allows an entity to be accessed outside its defining module, and `public`, which gives the same access level the former **and** allows the entity to be subclassed/overridden.
> 
> There's a clear overlap between `open` and `public`, as they essentially represent the same access control within the boundaries of a module, and do not add any benefit from outside them, as `final` is sufficient to prohibit subclassing/overriding.
> 
> Swift-evolution thread: ['Public' class visibility specifiers](https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html>)
> 
> 
> ## Motivation
> 
> Swift has currently 5 access levels, in the form of:
> 
> * `private`, restricting the use of an entity to its enclosing declaration;
> * `fileprivate`, restricting the use of an entity to its defining source file:
> * `internal`, restricting the use of an entity to its defining module;
> * `public`, allowing the entity to be accessed anywhere;
> * `open`, allowing the entity to be accessed anywhere **and** allowing the entity to be subclassed/overridden outside of their defining module.
> 
> From inside a module, `open` and `public` represent exactly the same access level (everything is visible **and** can be subclassed/overridden).
> From outside a module, `public` is actually akin to `final`.
> 
> ```swift
> // Module 1
> // ========
> 
> open class OpenClass {}
> public class PublicClass {}
> 
> public final class PublicFinalClass {}
> 
> // The first two classes above have the same access level.
> class derivedFromOpen: OpenClass {}
> class derivedFromPublic: PublicClass {}
> 
> // Module 2
> // ========
> 
> class derivedFromOpenOutside: OpenClass {}
> 
> class derivedFromPublicOutside: PublicClass {}
> // Error: Cannot inherit from non-open class ...
> 
> class derivedFromPublicFinalOutside: PublicFinalClass {}
> // Error: Inheritance from a final class ...
> ```
> 
> Hence, the sole use-case of using both `public` and `final` is for an entity that *inside* its defining module should not be subclassed/overridden.
> 
> ```swift
> // Module 1
> // ========
> 
> class derivedFromPublicFinal : PublicFinalClass {}
> // Error: Inheritance from a final class ...
> ```
> 
> We believe this use case is rare and not worth the additional complexity of having an `open` access level in the language.
> Besides, `open` is only applicable on classes and class members while the others can be used on other entities (protocols, structures, ...).
> This asymmetry adds to the complexity of an `open` access level.
> 
> In order to simplify the syntax of Swift, we propose to **remove the `open` access modifier**.
> 
> ## Proposal
> 
> Remove the `open` access modifier from Swift.
> 
> ## Source compatibility
> 
> This is a breaking change, as the `open` keyword would disappear from the language.
> However, a fixit would be quite easy to put in place, simply replacing `open` with `public`.
> 
> ## Alternative considered
> 
> Not removing the `open` access modifier from the language and keep the status quo.
> 
> _______________________________________________
> 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/20170221/379b0ceb/attachment.html>