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

[Matthew Johnson]

> On Dec 23, 2015, at 12:52 PM, Michel Fortin <michel.fortin at michelf.ca> wrote:
> 
> Le 23 déc. 2015 à 13:36, Matthew Johnson <matthew at anandabits.com <mailto: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.
> 

No, I don’t mean performance.  I mean that the code is significantly less clear when final is not the default.  It isn’t clear at all whether the author intended to allow subclasses or not when the default allows inheritance.  The value in making this clear is significant, especially if you are a new developer walking into a large application.

I don’t want to rehash the entire case here.  It has been discussed many times already on this list, most recently in the summary I posted this morning, as well as Kevin’s post from yesterday that I was replying to.

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