<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><div style="direction: inherit;">This is a detail of implementation and doesn't have to be. You might even imagine the compiler emitting two versions of the code, one assuming the class will not be subclassed, the other not assuming that, and a smart linker linking the right version depending on the case. </div><div style="direction: inherit;"><br></div><div style="direction: inherit;">So for me, in the long run, this argument is not an argument at all.</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Even then, is it really appropriate to sacrifice expressivity on the altar of (marginally) better performance?</div><div style="direction: inherit;"><br></div><div style="direction: inherit;">Jean-Denis</div></div><div><div style="direction: inherit;"><br></div>On 15 Aug 2016, at 09:50, Jean-Daniel Dupas via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><span></span><span>The non subclassable across module boundary is not just a compiler enforced limitation. Once you compile a module with classes that are ‘final’ in the module, the compiler may devirtualize all call sites in the module, or even inlining some calls, making subclassing unpredictable and pointless.</span><br><span></span><br><span></span><br><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>