<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 &lt;<a href="mailto:michel.fortin@michelf.ca" class="">michel.fortin@michelf.ca</a>&gt; 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 &lt;<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>&gt; 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.&nbsp;</div><div class=""><br class=""></div><div class="">My point is that it is best to design the language to address production concerns first. &nbsp;If the defaults in that design cause problems for prototyping and / or education it is<span class="Apple-converted-space">&nbsp;</span><i class="">possible</i><span class="Apple-converted-space">&nbsp;</span>to offer an environment with a modified default. &nbsp;I don’t know if that is a good idea or not. &nbsp;I am not a target user for either of those use cases (personally, I would rather prototype with the production language). &nbsp;Either way, it is<span class="Apple-converted-space">&nbsp;</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">&nbsp;</span><b class="">strongly</b>&nbsp;feel that I shouldn’t pay a price in production code in order to better support those use cases. &nbsp;IMO ‘final’ is the right default for production code and we pay a price if the default is anything less, including ‘sealed’.&nbsp;</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&nbsp;<i class="">only</i>&nbsp;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. &nbsp;I mean that the code is significantly less clear when final is not the default. &nbsp;It isn’t clear at all whether the author intended to allow subclasses or not when the default allows inheritance. &nbsp;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. &nbsp;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>