[swift-evolution] 'Public' class visibility specifiers

[Brent Royal-Gordon]

> On Feb 21, 2017, at 3:15 AM, Joanna Carter <joanna at carterconsulting.org.uk> wrote:
> 
> Now, if it was decided that non-inheritable would be the default for classes :
> 
> 1. that's only true for inheritance outside of a module

Yes. As SE-0117 explains, the danger of subclassing is that, if the author of the superclass doesn't expect it and design for it, the subclass can accidentally interfere with the superclass's normal operation. It was felt that this problem is most acute with public classes, where potential subclass authors often have little relationship to the superclass's author and may not have access to the superclass's source code at all. Therefore, as a pragmatic trade-off between safety and convenience, subclassing is permitted by default except for `public` classes.

> 2. why leave 'final' in place (apart from Slava's reasons)?

There were a number of minor reasons like Slava's, but ultimately, it was felt that `final` is helpful both for non-`public` classes (where it documents that the class is never intended to be subclassed) and for `public` APIs (where it documents that there are no non-`public` subclasses, that there will never *be* non-`public` subclasses in later versions of the library, and that therefore method calls can be made statically).

> 3. if inheritance of classes, which is a form of extension, is restricted outside of a module, why are extensions of a type allowed without restriction ?

Again, this was explained in SE-0117. Extensions cannot override anything (or access anything about the class that isn't publicly available, since we don't have the `extensible` modifier you proposed), so there's no danger that an extension could interfere with the normal operation of the class. That's not true for subclasses, which can override superclass behavior and change it.

-- 
Brent Royal-Gordon
Architechies