[swift-evolution] Final by default for classes and methods
michel.fortin at michelf.ca
Wed Dec 23 12:52:05 CST 2015
Le 23 déc. 2015 à 13:36, Matthew Johnson <matthew at anandabits.com> a écrit :
>> I'm not sure why you say the last two should be addressed separately from the "production" language. Are you proposing Swift should come in multiple language variants?
> Not exactly.
> My point is that it is best to design the language to address production concerns first. If the defaults in that design cause problems for prototyping and / or education it is possible to offer an environment with a modified default. I don’t know if that is a good idea or not. I am not a target user for either of those use cases (personally, I would rather prototype with the production language). Either way, it is possible, just as it is possible to have @testable to facilitate unit testing.
> I strongly feel that I shouldn’t pay a price in production code in order to better support those use cases. IMO ‘final’ is the right default for production code and we pay a price if the default is anything less, including ‘sealed’.
By "pay a price" you mean diminished performance, right? That would depend on the ABI (which hasn't been discussed much yet, is there some preliminary docs about it?).
I don't think there is a price in performance to pay for sealed. You simply call a static function in the library, and that static function does the dynamic dispatch only if the library contains some overrides for that function. If there's no override it's simply purely a static call.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution