<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:52 PM, Michel Fortin <<a href="mailto:michel.fortin@michelf.ca" class="">michel.fortin@michelf.ca</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="">Le 23 déc. 2015 à 13:36, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> a écrit :<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"><div class=""><div style="font-family: HelveticaNeue; font-size: 13px; 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="">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?</div><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><br class=""></div></div></div></blockquote><div class=""><br class=""></div><div class="">Not exactly. </div><div class=""><br class=""></div><div class="">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<span class="Apple-converted-space"> </span><i class="">possible</i><span class="Apple-converted-space"> </span>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<span class="Apple-converted-space"> </span><i class="">possible</i>, just as it is possible to have @testable to facilitate unit testing.</div><div class=""><br class=""></div><div class="">I<span class="Apple-converted-space"> </span><b class="">strongly</b> 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’. </div></div></div></blockquote><br class=""></div><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><br class=""></div></div></blockquote><div><br class=""></div><div>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><br class=""></div><div>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.</div></div><br class=""><div class="">Matthew</div></body></html>