To those people I would say use final or let's change public to mean the current open and replace open with 'module'...
I liked open by default and this not needing open in the first place... you guys got me here ;). Sent from my iPhone > On 21 Feb 2017, at 07:02, David Hart via swift-evolution > <swift-evolution@swift.org> wrote: > > 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@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution