<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="">This is the case with a library.</div><div class=""><br class=""></div><div class="">It is *not* the case with a framework. Dynamically linked frameworks can be changed without the app even being changed. Imagine if Apple changed UIKit and make UINavigationController final retroactively. UIKit internally would therefore call directly to the UINavigationController methods statically, and bypass any subclass’s methods, thereby breaking applications. Should app apps have to be rebuilt to work with iOS 12 simply because Apple shipped a new version of UIKit? This is illogical. You will *break* things by finalising after the fact. Swift, being about safety, needs to deal with this safely.</div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On 11 Jul 2016, at 9:13 AM, Tino Heth <<a href="mailto:2th@gmx.de" class="">2th@gmx.de</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=""><div class=""><br class=""><blockquote type="cite" class=""><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="">The problem with this is simple: you cannot retroactively "close up" an API. I cannot add final to a class I have previously declared as non-final. I also can seal a class which has previously been open to subclassing.</div></div></blockquote></div>Of course you can do both — it may make users angry, but so what?<div class="">The essence of this way of thinking is "I fear the reaction of my users when I take something away from them… so I have to deny them those options right from start".</div><div class=""><br class=""></div><div class="">I've no statistics (there's a general lack of facts all over the place…), but I don't thing the majority of todays and future libraries are build with a strictly planned top-down approach and guarantees about API-stability. Nowadays things are much more spontaneous, and the strict rules and limits some people here want to force upon others would most likely decrease the joy in playing with the language and start experiments in it.</div><div class=""><br class=""></div><div class="">There is only a very small number of Swift-developers writing frameworks that are used on a large scale basis, and even if many people in this group vote for limiting defaults, the focus should be on the majority:</div><div class="">When I come to the conclusion that a set of classes in a project could be useful somewhere else, my problem is not fear of future API changes — it is the daunting task of having to sprinkle "public" all over the place.</div><div class="">Sealing classes makes proper code reuse a more tedious job, and I want Swift to stay fun rather than become a playground for sticklers for order.</div></div></div></blockquote></div><br class=""></body></html>