<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:26 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 à 10:07, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :<br class=""><div class=""><blockquote type="cite" class=""><br class="Apple-interchange-newline"></blockquote><div style="font-family: HelveticaNeue;" class=""></div><blockquote type="cite" class=""><div style="font-family: HelveticaNeue;" class="">3) <b class="">Annoyance</b>. Some consider it to be annoying to have to annotate a class declaration in order to inherit from it. People stating this argument either are either writing a lot of superclasses or are so bothered by the need to annotate their type declarations that they avoid `final` and its related benefits when that is really the right thing for their class. For me personally, `final` is the right thing for most classes I write. I also think adding a `final` annotation is the right thing to do if you’re not sure whether it will be a superclass or not. The need to modify the annotation will remind you that you haven’t fully considered inheritance in your design yet.</div></blockquote><div class=""><blockquote type="cite" class=""><br class=""></blockquote><blockquote type="cite" class="">...</blockquote><blockquote type="cite" class=""><br class=""></blockquote></div><blockquote type="cite" class=""><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="">5)<span class="Apple-converted-space"> </span><b class="">Prototyping</b>. This should also not influence the decision about what the default is for production code. I would not have a problem with a prototyping environment allowing `inheritable` by default (maybe a Playground mode?). There could even be a tool that migrates the prototype to a real project and adds the `inheritable` annotation where necessary. Regardless of what happens here, the prototyping problem can and should be solved independently of the production language and should not influence the default is used in and impacts production code.</div><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=""><br class=""></div><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="">6)<span class="Apple-converted-space"> </span><b class="">Education</b>. There may be some value in allowing inheritance by default in education settings, especially early on. I view this as being quite similar to the prototyping case and again should not have an influence on the default that professionals use in production code.</div></div></blockquote><br class=""></div><div class="">I think these three concerns would be addressed in good part by having sealed by default instead of `final`.</div><div class=""><br class=""></div><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=""><br class=""></div></div></div></blockquote><div><br class=""></div><div>Not exactly. </div><div><br class=""></div><div>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 <i class="">possible</i> 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 <i class="">possible</i>, just as it is possible to have @testable to facilitate unit testing.</div><div><br class=""></div><div>I <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><br class=""></div></div>Matthew</body></html>