<div dir="ltr">&gt; the dynamic nature and possible overridability of even things that Apple doesn’t<div>&gt; specifically intend to allow overriding is one of the primary reasons why AppKit has</div><div>&gt; survived for 20+ years and spawned arguably the most successful application</div><div>&gt; framework in history in UIKit.<div><br></div></div><div><div>Aren&#39;t we mixing up two different issues here? &quot;Having a default final for Swift classes&quot; should be treated as a separate issue from &quot;Apple frameworks should stay overridable&quot;.</div><div><br></div><div>They are different issues because:</div><div><br></div><div> (a) Even if final was not the default, any framework vendor can mark its classes final. The only thing we can do is trust Apple to maintain the status quo (monkey-patchable) for its current and future frameworks - we can&#39;t just hope they&#39;ll forget to override a default of non-final.</div><div><br></div><div> (b) If / when there&#39;s a Swift-written binary framework, if it has to expose its methods to Objective-C (with @objc / dynamic), it would have to become monkey-patchable.</div><div><br></div><div>So, while we definitely need the ability to override Apple&#39;s frameworks (now and in the future), that DOES NOT count as a reason to say that final shouldn&#39;t be the default.</div><div><br></div><div>If we take that out of the equation, this proposal can be seen in terms of these questions:</div><div><br></div><div> 1. Within a module, should I be able to override my own classes / methods by default, or should I have to explicitly mark those classes as overridable to do that?</div><div><br></div><div> 2. If I&#39;m releasing a Swift binary framework, and I haven&#39;t yet thought about which classes / methods should be overrideable, should I release it in </div><div> everything-is-overridable mode, or in nothing-is-overridable mode?</div><div> </div><div>    (Note that if I make a release now in everything-is-overridable mode, I can&#39;t make a binary-compatible release in the future with reduced overridability.)</div><div><br></div><div> 3. If I&#39;m using a third-party (non-Apple) Swift binary framework, and if the framework author hadn&#39;t really thought about which classes / methods should be overrideable, would I want the power to override everything in the framework now?</div><div><br></div><div>    (Note that if I get that power, I forgo all hope of getting a binary-compatible update to the framework with correct annotations about which classes can be safely overridden and which aren&#39;t meant to be overridden.)</div><div><br></div><div>In questions 2 &amp; 3, I&#39;m focusing only on binary frameworks because if the source code was available, it would be possible to modify the source to override whatever we wanted - so overriding or patching would be possible, only maybe inconvenient.</div><div><br></div><div>Personally, my answers for the above questions will be:</div><div><br></div><div> A1: Within my own module, I&#39;d like to have all classes overridable by default</div><div> A2: If I haven&#39;t thought about overridability in my framework, I&#39;d rather release it now in nothing-is-overridable mode, and retain the ability to fix it in an update.</div><div> A3: Ideally, I&#39;d like to be able to override everything in the framework I use, but if that implies that I can&#39;t get a binary-compatible fix to the framework, maybe I can live without that overridability.</div><div><br></div><div>Therefore, I&#39;d support a proposal to make classes in the module&#39;s public interface final-ized by default.</div><div><br></div><div>As to naming/syntax, I suggest this:</div><div><br></div><div>    public class C1 { } // Can&#39;t subclass</div><div><br></div><div>    public class C2 {   // Can subclass because it has an </div><div>                        // overridable method</div><div>        func f1() { }             // Can&#39;t override</div><div>        overridable func f1() { } // Can override</div><div>    }</div><div><br></div><div>    overridable public class C3 { // Can subclass</div><div>        func f1() { }             // Can override</div><div>        func f1() { }             // Can override</div><div>    }</div><div><br></div><div>Thanks,</div><div>roop.</div></div><div><br></div></div>