[swift-evolution] [swift-evolution-announce] [Review] SE-0117: Default classes to be non-subclassable publicly

Tino Heth 2th at gmx.de
Mon Jul 11 06:34:00 CDT 2016

I haven't read the whole Library Evolution document, but one important part is written right at the top:

> 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 Swift Package Manager <https://swift.org/package-manager/>)

So there are compelling arguments to "seal" the Apple-libraries, and it's reasonable to enforce sealing on them.
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.
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:
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). 

> Am 11.07.2016 um 05:38 schrieb Jordan Rose via swift-evolution <swift-evolution at swift.org>:
> 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.
Once again a situation where we have to differentiate wether we encourage open source or not:
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.
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.

For software that grows "organically", documentation is more useful than simple rules...
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/2d9e6dda/attachment.html>

More information about the swift-evolution mailing list