<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 23, 2015, at 12:59 PM, Stephen Celis <<a href="mailto:stephen.celis@gmail.com" class="">stephen.celis@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 23, 2015, at 1:55 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">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?).</div><div class=""><br class=""></div><div class="">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 <i class="">only</i> if the library contains some overrides for that function. If there's no override it's simply purely a static call.</div></div></div></blockquote><div class=""><br class=""></div><div class="">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.</div></div></div></blockquote><br class=""></div><div class="">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.</div></div></div></blockquote><br class=""></div><div>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.</div><div><br class=""></div><div>Matthew</div><br class=""></body></html>