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

[Goffredo Marocchi]

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 at 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 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.
>> 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 at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> 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/2e4c4360/attachment.html>