[swift-evolution] 'Public' class visibility specifiers

[Joanna Carter]

> Le 21 févr. 2017 à 12:02, Brent Royal-Gordon <brent at architechies.com> a écrit :
> 
>> On Feb 20, 2017, at 8:47 AM, Joanna Carter via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> When it comes to visibilities on classes, why, oh why do we have public vs open *as well as*
>> the option of marking stuff as final?
> 
> We had an enormous, weeks-long, *hugely* contentious debate about whether to introduce `open`, and the end result was that SE-0117 was revised several times and finally approved. It describes the rationale concisely, but pretty well: <https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md>
> 
> It doesn't *specifically* address why `final` was kept as well, but essentially, as the Motivation section describes, we wanted non-inheritable to be the default for public classes, so developers would have to specifically choose to open their classes to public subclassing. That meant that having `public` make the class subclassable would not fulfill our goals.
> 
> Look. It's not forbidden to re-litigate old design decisions, but if you're going to do it, you should at least study the original proposal and be prepared to either attack flaws in the Motivation section or show why the Proposed Design does not address the problem. Preferably, you should base your argument knowledge from later experience--things we did not know when we reviewed the proposal. You're not saying anything in this thread that wasn't said over and over again in a series of sprawling, stressful near-flamewars last summer.
> 
> Please don't tear open old wounds unless you at least have a new treatment to try.

Firstly, let me apologise for any hurt caused, but it is quite difficult to carry on with you own projects *and* keep track of everything that is going on is Swift Evolution, especially with the current mailing list format, with interminable repeat quoting of whole threads in a single digest email.

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

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

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 ?

Not forgetting that this discussion was started by me as part of a wider discussion of visibility and extensibility specifiers in general :-)

--
Joanna Carter
Carter Consulting