<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 Jul 6, 2016, at 4:34 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><div class=""><br class=""></div><div class="">Many of us believe “final” is too blunt a tool. There are many cases where final cannot be used but you still don’t want external users subclassing or overriding. </div><div class=""><br class=""></div><div class="">We would like a more precise tool for these circumstances and believe if it is going to exist in Swift it should be the default. Its behavior follows the principle of requiring programmers to explicitly make decisions about what behavior is exposed outside of a module. You may not like that principle, but it is one that has been embraced by the language.</div><br class=""></div></div></blockquote><div><br class=""></div><div>I am all for these things, and would be in favor of a proposal that does this cleanly(*)… the proposal text I reviewed does not.</div><div><br class=""></div><div>* e.g. the final/sealed/open keywords you suggest, with sealed being the new default, makes a huge amount of sense to me and feels clean, since it keeps access and finality separate, and as you say, explicitly make decisions in a manner otherwise consistent with the language.</div><div><br class=""></div><div>Scott</div></div></body></html>