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

[Matthew Johnson]

> On Dec 23, 2015, at 12:59 PM, Stephen Celis <stephen.celis at gmail.com> wrote:
> 
>> On Dec 23, 2015, at 1:55 PM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto: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.

I see the analogy, but IMO the issues involved in access control vs inheritance are significantly different.  I agree with the default of internal for access control.  However, I don’t want to get this thread sidetracked on the reasons why it is different and why I agree with that default.

Matthew

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