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 <[email protected]> wrote: >> >> On Jul 6, 2016, at 1:16 PM, Leonardo Pessoa <[email protected]> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
