<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="">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><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>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><br class=""></div><div>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 apple-content-edited="true" class="">
<div style="color: rgb(0, 0, 0); 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; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); 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; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; line-height: normal; border-spacing: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; border-spacing: 0px; -webkit-text-decorations-in-effect: none; -webkit-text-stroke-width: 0px;"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">-- <br class="">Michel Fortin<br class=""><a href="https://michelf.ca" class="">https://michelf.ca</a></div></span></div></span></div></span></div></div></div>
</div>
<br class=""></body></html>