<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="">I haven't read the whole Library Evolution document, but one important part is written right at the top:<div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-size: 14px; text-align: justify; background-color: rgb(255, 255, 255);" class="">This model is largely not of interest to libraries that are bundled with their clients (distribution via source, static library, or embedded/sandboxed dynamic library, as used by the </span><a class="external reference" href="https://swift.org/package-manager/" style="font-weight: bold; color: rgb(85, 26, 139); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-size: 14px; text-align: justify;">Swift Package Manager</a><span style="color: rgb(51, 51, 51); font-family: 'DejaVu Sans', Arial, Helvetica, sans-serif; font-size: 14px; text-align: justify; background-color: rgb(255, 255, 255);" class="">)</span></blockquote></div><div class=""><br class=""></div><div class="">So there are compelling arguments to "seal" the Apple-libraries, and it's reasonable to enforce sealing on them.</div><div class="">But if sealed is the right default for those libraries, it is not automatically the right default for all other libraries out there, because those are developed in a completely different manner.</div><div class="">So, instead making sealed the default for Swift, I believe it is much more sound to just make it the default for the standard frameworks:</div><div class="">This doesn't break compatibility, it's imho more convenient for the majority, and I guess there is enough manpower to manage the annotations for Cocoa and other frameworks (which is tedious labor for single developers, but no issue for a large company). </div><div class=""><br class=""></div><div class=""><div><blockquote type="cite" class=""><div class="">Am 11.07.2016 um 05:38 schrieb Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>>:</div><br class="Apple-interchange-newline"><div class=""><div class="" 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;">While an overridable method may have particular preconditions and postconditions, it’s possible that the overrider will get that wrong, which means the library author can no longer reason about the behavior of their program.</div></div></blockquote><div>Once again a situation where we have to differentiate wether we encourage open source or not:</div><div>In OS, users of a library become the allies of its author — they can put stress on his model, they can find its flaws and they can show him how to improve.</div><div>The ability to take a piece of code and start playing with it is a fantastic trait, and this is actively discouraged by imposing limits not because they make sense, but only because the original author didn't take the time to reason about the status.</div><div><br class=""></div></div>For software that grows "organically", documentation is more useful than simple rules...</div><div class="">I like the concept of version blocks, and it could work in the other direction as well: We could have a "experimental"-modifier that would give the library author a way to offer hints for its clients, but leaves the final decision up to them. This would be much more granular than a plain "final" which not only protects those who want to stay on the safe side, but also repels the bold developers who'd willingly help improving the code in question.</div></body></html>