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

[Matthew Johnson]

> On Jul 21, 2016, at 3:13 AM, Tino Heth via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> 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…)

Not at all - `closed` and `sealed` are two different names proposed for the same thing but `final` is very different.  If you are using a `final` type from a library you (and the compiler) know all variables of that type reference instances of *exactly* that type.  You do not get that guarantee with `closed` / `sealed`.  In that case a variable may reference a subclass defined in the same module as the type of the variable.

The similarity is that outside the defining module you cannot subclass `final` or `closed` types.  But the rest of the semantics are quite different.

> 
> 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
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution