<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>To those people I would say use final or let's change public to mean the current open and replace open with 'module'...</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">I liked open by default and this not needing open in the first place... you guys got me here ;).<br><br>Sent from my iPhone</div><div><br>On 21 Feb 2017, at 07:02, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8">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.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 21 Feb 2017, at 07:44, Dimitri Racordon via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
Hi all,
<div class=""><br class="">
</div>
<div class="">Here’s a draft proposal following <span style="white-space: pre-wrap;" class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html</a>.
</span>The idea is simplify Swift’s syntax by getting rid of the `open` access modifier.</div>
<div class=""><br class="">
</div>
<div class="">A rendered version of the proposal is available here: <a href="https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/nnnn-remove-open-access-modifier.md" class="">https://github.com/kyouko-taiga/swift-evolution/blob/master/proposals/nnnn-remove-open-access-modifier.md</a></div>
<div class="">The raw version follows:</div>
<div class=""><br class="">
</div>
<div class="">
<pre style="word-wrap: break-word; white-space: pre-wrap;" class=""># Remove open Access Modifier
* Proposal: [SE-NNNN](nnnn-remove-open-access-modifier.md)
* Author: [Dimitri Racordon](<a href="https://github.com/kyouko-taiga" class="">https://github.com/kyouko-taiga</a>), 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](<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170220/032576.html</a>)
## 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.</pre>
<div class=""><br class="">
</div>
</div>
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>