[swift-evolution] Final by default for classes and methods

[Michel Fortin]

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.

-- 
Michel Fortin
https://michelf.ca

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151223/afabd8d0/attachment.html>