> On Dec 23, 2015, at 12:59 PM, Stephen Celis <stephen.ce...@gmail.com> wrote: > >> On Dec 23, 2015, at 1:55 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
