[swift-evolution] 'Public' class visibility specifiers

[Brent Royal-Gordon]

> 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.

-- 
Brent Royal-Gordon
Architechies