[swift-evolution] [Proposal] Sealed classes by default

Jean-Denis Muys jdmuys at gmail.com
Mon Aug 15 03:31:16 CDT 2016

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. 

So for me, in the long run, this argument is not an argument at all.

Even then, is it really appropriate to sacrifice expressivity on the altar of (marginally) better performance?


> On 15 Aug 2016, at 09:50, Jean-Daniel Dupas via swift-evolution <swift-evolution at swift.org> wrote:
> 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.
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160815/26e0e19d/attachment.html>

More information about the swift-evolution mailing list