While I am in favor of this, I do think this should not be a proposal on its own, rather it should be folded into a general overhaul of the entire access level structure.
Regards, Rien Site: http://balancingrock.nl Blog: http://swiftrien.blogspot.com Github: http://github.com/Balancingrock Project: http://swiftfire.nl > On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution > <swift-evolution@swift.org> wrote: > > Hi all, > > Here’s a draft proposal following > 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 > 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 > ), 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 > ) > > > ## 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@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