[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

[Scott James Remnant]

> 
> On Jul 6, 2016, at 1:16 PM, Leonardo Pessoa <me at lmpessoa.com> wrote:
> 
> Scott, I think your writing got a bit confuse but, if I got your
> intention right, since you are the owner of the class, you may choose
> to subclass it or not internally, no questions asked.

No.

This is how the language exists today:

1a. Default access control is `internal`, and may be modified by adding the `public`, `fileprivate`, or `private` keyword, as appropriate.

1b. All classes may be subclassed, and all methods, properties, and subscripts overridden. This can be prevented by adding the `final` keyword.

The two concepts are very separate, and I think this is a good thing.


What this proposal suggests, whether or not `final` is kept or removed, is that the two concepts become conflated:

2a. Default access control is `internal`, and may be modified by adding the `public`, `fileprivate`, or `private` keyword, as appropriate.

2b. Non-`public` classes may be subclassed, and non-`public` methods, properties, and subscripts overridden. This can be prevented by adding the `final` keyword.

2c. `public` classes may not be subclassed. To allow this replace the `public` keyword with `subclassable`

2d. `public` methods, properties, and subscripts may not be overridden. To allow this replace the `public` keyword with `overiddable`.


Removing the `final` keyword means a change to 2b above. The first option is simply to throw it away, in which case you end up with:

3a. Default access control is `internal`, and may be modified by adding the `public`, `fileprivate`, or `private` keyword, as appropriate.

3b. Non-`public` classes may be subclassed, and non-`public` methods, properties, and subscripts overridden. This can be never be prevented.

3c. `public` classes may not be subclassed. To allow this replace the `public` keyword with `subclassable`

3d. `public` methods, properties, and subscripts may not be overridden. To allow this replace the `public` keyword with `overiddable`.


The second option is to throw it away, and adjust the default behavior so it truly is `final` as removing the keyword would imply. Then you end up with:

4a. Default access control is `internal`, and may be modified by adding the `public`, `fileprivate`, or `private` keyword, as appropriate.

4b. Non-`public` classes may not be subclassed, and non-`public` methods, properties, and subscripts may not be overridden. This can never be allowed.

4c. `public` classes may not be subclassed. To allow this replace the `public` keyword with `subclassable`

4d. `public` methods, properties, and subscripts may not be overridden. To allow this replace the `public` keyword with `overiddable`.


To me all of these options take a clean, easy-to-understand, language design (1) and turn it into various states of mess. Removing the `final` keyword not only makes it a mess, but removes functionality—the ability to have a mix of final and non-final classes, methods, properties, and subscripts, accessible only within your own module.

Scott