
<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><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></body></html>