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

[Leonardo Pessoa]

So I did get what you meant right. Now tell me: if a class or method
is internal to your module (and you know internal means only you,
throught your source code, inside your app or library can extend it),
do you really need to mark anything as final for any reason? Final on
any non-publics is a restriction you put on yourself, you will always
have the power to lift that at any time (as long as you still own the
code, of course) so you are always in control of your subclasses and
overrides. All the time. It's up to you to subclass/override or not.
This is different from what you make public: you either have no
control or you have to fine grain control making everything final. You
regain that control over your publics with this proposal.

You can also try and simplify your outlines reducing X.c and X.d to a
single entry as it is the same rule applied to two different elements
of the language. Using one single keyword (such as in 'open') would
make it clearer and that is why I prefer to have only one keyword.

So, AFAICS, number 3 is how it should be with this proposal. As for
keeping the final keyword (sticking with number 2), I think it is up
to the community. I myself don't see any reason/need for it should
this proposal pass.

L

On 6 July 2016 at 17:32, Scott James Remnant <scott at netsplit.com> wrote:
>>
>> 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