<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 21 Feb 2017, at 12:15, Joanna Carter via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><br class=""><blockquote type="cite" class="">Le 21 févr. 2017 à 12:02, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> a écrit :<br class=""><br class=""><blockquote type="cite" class="">On Feb 20, 2017, at 8:47 AM, Joanna Carter via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class="">When it comes to visibilities on classes, why, oh why do we have public vs open *as well as*<br class="">the option of marking stuff as final?<br class=""></blockquote><br class="">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: <<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0117-non-public-subclassable-by-default.md</a>><br class=""><br class="">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.<br class=""><br class="">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.<br class=""><br class="">Please don't tear open old wounds unless you at least have a new treatment to try.<br class=""></blockquote><br class="">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.<br class=""><br class="">Now, if it was decided that non-inheritable would be the default for classes :<br class=""><br class="">1. that's only true for inheritance outside of a module<br class=""></div></div></blockquote><div><br class=""></div><div>I think that’s what he meant.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">2. why leave 'final' in place (apart from Slava's reasons)?<br class=""></div></div></blockquote><div><br class=""></div><div>It’s debatable, and if something is worth considering for removal its final. I’ve asked that exact question last month in the "<span style="color: rgba(0, 0, 0, 0.85098); font-family: 'Helvetica Neue';" class=""><b class="">final + lazy + fileprivate modifiers</b>" thread got some interesting counter arguments:</span></div><div><span style="color: rgba(0, 0, 0, 0.85098); font-family: 'Helvetica Neue';" class=""><br class=""></span></div><div><span style="color: rgba(0, 0, 0, 0.85098); font-family: 'Helvetica Neue';" class=""><b class="">Matthew Johnson:</b></span></div><div><div class="">My experience is that it is a very useful communication of intent to future readers of the code.</div><div class="">That aside, I think the criteria for a change are different now. Your criteria were relevant during the big breaking change era of Swift 3. I think the criteria for removing a feature at this point should be: is it causing problems that justify the breaking change required to remove it?</div><div class=""><br class=""></div><div class=""><b class="">Charlie Monroe:</b></div><div class=""><div class="">To me, it's useful a lot. The module doesn't necessarily be a 1KLOC framework - I've been recently refactoring a 90KLOC module and the final keyword was fairly useful since some subclasses used hacks by overriding some vars or methods. This allowed me to look at it from a different perspecitve, make some members final and create better API endpoints for customization.</div><div class="">Not to mention that it allows the compiler to access stored properties directly when they're final - if I recall correctly someone from the core team mentioning that.</div></div><div class=""><br class=""></div><div class=""><b class="">Derrik Ho:</b></div><div class="">I find the final keyword useful when I want to communicate that this class should not be subclassed.<br class="">I think the behavior should remain the same since it is useful.</div></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">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 ?<br class=""></div></div></blockquote><div><br class=""></div><div>Because extensions don’t have the same pitfalls as subclassing. The Motivation section of the proposal that introduced open that Brent linked has a very detailed explanations of the pitfalls of subclassing.</div><br class=""><blockquote type="cite" class=""><div class=""><div class="">Not forgetting that this discussion was started by me as part of a wider discussion of visibility and extensibility specifiers in general :-)<br class=""><br class="">--<br class="">Joanna Carter<br class="">Carter Consulting<br class=""><br class="">_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></div></blockquote></div><br class=""></body></html>