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