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

[Stephen Celis]

> On Dec 23, 2015, at 1:55 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org> wrote:
>> 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.

While I agree with you, the same argument can be made for modules where `internal` code isn't marked `private`. Existing access control makes a case for `sealed` being the default, though I think class subclassing happens less frequently, and thus could be made `final` by default and utilize fix-its to make marking things inheritable simple enough.

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