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

[Dimitri Racordon]

Hi David,

Thanks for your feedback.
Do you have yourself an example in which a final entity would be clearly needed inside its module?

I have seen theoretical use-cases already, but haven’t encountered a “real-life” situation that’d need this pattern yet.

On 21 Feb 2017, at 08:02, David Hart <david at hartbit.com<mailto:david at hartbit.com>> 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<mailto: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<mailto: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/fe5a4485/attachment.html>