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

Jean-Daniel Dupas mailing at xenonium.com
Wed Jun 29 01:33:43 CDT 2016


> Le 29 juin 2016 à 01:01, Michael Peternell via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 
>> Am 29.06.2016 um 00:32 schrieb John McCall <rjmccall at apple.com>:
>> 
>> The decision to make class methods polymorphic by default was always premised on being able to undo that in obvious cases where methods are never overridden.  Making a class public so that clients can use it shouldn't cause significant performance degradations just because you forgot to also write "final".
>> 
>> John.
> 
> I do care about performance. For this reason I don't want a fully dynamic language. I disagree about the "significant performance degradations just because you forgot to also write `final`". I mentioned "performance" in my original post only because it would be the only convincing argument - if there were indeed superior performance when using `final`.
> 
> Of course, dynamic dispatch is much slower than static dispatch. But optimized code does not spend much time dispatching. If a method takes 3 seconds to complete, and from that 2 seconds are used for dynamically dispatching method calls, then I would say that it has not been optimized for performance yet. How would such a function look like? The function being dynamically dispatched should probably not be statically dispatched but inlined completely. And for the rare case that the dispatch type really makes all the difference, it's always possible to `final`ize (or `private`ize) some of the used methods.

Swift dynamic dispatch is not Obj-C dynamic dispatch. Talking about the cost of dynamic dispatch without real benchmark is premature optimization IMHO.




More information about the swift-evolution mailing list