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

[Tino Heth]

> Am 21.07.2016 um 03:41 schrieb Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org>:
> 
> A class that is closed in 1.0 can be opened in 1.1; a class that is `final` in 1.0 *cannot* be opened in 1.1 (or at least it's a breaking change if it is).
Wait a moment: Aren't "closed", "sealed" and "final" basically all the same as soon as you cross module borders? (but I guess it's just that some words are in wrong order…)

But anyways, the imho important part is between the parenthesis:
Of course you can rename public properties, mark methods as final, rename all your classes or delete the repository of your library easily.
It might break other peoples code and make them angry, but if this is the driving motivation for SE-0117, the whole proposal is a paradox:
Changing the default for subclassability will break other peoples code on a gigantic scale — not only single methods or classes, but nearly every framework.

Just imagine this fear of breaking changes had been applied to Swift… do you think it would have been better for the progress of the language?
I don't think so, and I think that libraries aren't that different in this aspect:
When you start something new, you want breaking changes happen as soon as possible, when there is the most tolerance for them.

As I keep saying for a long time, I think that attitude is an aspect that is terribly neglected here, and imho there are already enough established languages which are pulled down by fear of breaking changes.
Although I have problems sorting out what "swifty" actually means, I might have a longer history as an Apple-customer than most other discussants here, and all marketing aside, there is one distinguishing principle that can be illustrated with many examples:
Better products are preferable over stable products.

- Tino