<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=""><div class=""><blockquote type="cite" class="">On 23 Dec 2015, at 7:20 AM, Tino Heth via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</blockquote><blockquote type="cite" class="">You're quite right, but imho the whole issue is bigger than a few characters that have to be typed to get the desired inheritance characteristic: That would not drive discussion that long.<br class="">It's also about the philosophy that backs the choice, it is freedom vs. safety, and any default value is a statement in favor of one of the extreme positions — and it is a little push for anyone designing a library, including those who work at Apple.<br class=""><br class="">The idea of encouraging an explicit choice has value; I think a proposal to have no default at all wouldn't have created such a big debate...<br class=""></blockquote></div><div class=""><br class=""></div><div class=""><font face="AvenirNext-Regular" class="">And that is ultimately the crux of this issue, isn’t it?</font></div><div class=""><font face="AvenirNext-Regular" class=""><br class=""></font></div><div class=""><font face="AvenirNext-Regular" class="">If Swift defaults to finality or “sealed", this could end up with every framework allowing very minimal subclassing just by a matter of culture, which I think we all agree with frameworks like UIKit showing where this is really probably not what we want.</font></div><div class=""><font face="AvenirNext-Regular" class=""><br class=""></font></div><div class=""><font face="AvenirNext-Regular" class="">If Swift defaults to open, then we have more compatibility problems if a class is, further down the road, final or sealed, and the performance benefits of Swift would be marginal at best.</font></div><div class=""><font face="AvenirNext-Regular" class=""><br class=""></font></div><div class=""><font face="AvenirNext-Regular" class="">I think at this stage, we have to begrudgingly accept that external subclassing will be disabled by default. The problems with open-by-default are simply too many and varied, as has been discussed at length here. Framework vendors will probably close their own classes manually anyway if it’s not there.</font></div><div class=""><font face="AvenirNext-Regular" class=""><br class=""></font></div><div class=""><font face="AvenirNext-Regular" class="">Whether closing the classes takes place as “sealed” or “final” is a matter for more debate. Personally I support Sealed, but I wonder whether that has implications for compiler optimisations when it cannot assume that “sealed means final” because a framework could potentially vend me a private subclass of the sealed class.</font></div><div class=""><font face="AvenirNext-Regular" class=""><br class=""></font></div><div class=""><font face="AvenirNext-Regular" class="">-Rod</font></div></body></html>