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

[Matthew Johnson]

> On Jul 9, 2016, at 7:43 AM, Andre <pyunpyun at me.com> wrote:
> 
> Hi,
> 
>> However, you *do not* want any new subclasses added as you know that is not likely to end well. 
> Im curious, what kind of real-world scenario would "not end well" cover?

Any kind of scenario where you need to preserve invariants which could be difficult to preserve if you have to anticipate what 3rd party subclasses might do in their implementations / overrides.

I have seen some comments about nontrivial complexity in Apple’s frameworks caused by apps subclassing where they should not have (i.e. classes that would be sealed if it were possible in Objective-C).  This is extremely unfortunate and it impacts everyone on Apple’s platforms.

I wish I had links handy for you, but I don’t recall exactly where or when this was mentioned and don’t have time to dig them up right now.

> 
> I’m genuinely curious, since Im still on the fence about this, but am willing to be convinced… if sealed by default brings more positives than negatives…
> 
> Thanks in advance.
> 
> Andre
> 
> 
>> 2016/07/09 21:36、Matthew Johnson via swift-evolution <swift-evolution at swift.org> のメール：
>> 
>> 
>> 
>> Sent from my iPad
>> 
>>> On Jul 9, 2016, at 3:48 AM, Goffredo Marocchi via swift-evolution <swift-evolution at swift.org> wrote:
>>> 
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 8 Jul 2016, at 15:09, Károly Lőrentey via swift-evolution <swift-evolution at swift.org> wrote:
>>>> 
>>>> Even in Java, it is a bad idea to leave classes subclassable; but having to remember to add final is a chore.
>>> 
>>> I still think it is worth doing that chore. The fact of the matter is that Java did not and is not enforcing that default and how many widely used production languages you know that do enforce this by default instead of asking library authors to do this bit of work?
>> 
>> People keep talking about just adding final.  This *is not* an alternative.  We are not talking about preventing subclasses by default (i.e. final by default).  
>> 
>> We are talking about preventing subclasses *in other modules* by default (i.e. sealed by default).  The alternative would be to introduce a sealed keyword (or similar).
>> 
>> There are times when you *need* to use subclasses inside your module.  Some or all of them may not even be directly visible externally (class clusters).  However, you *do not* want any new subclasses added as you know that is not likely to end well.  This is why having sealed, not just final, is important.
>> 
>> By choosing sealed as a default rather than final, we are keeping the "subclassable by default" status *within* modules.  This facilitates experimentation and eliminates the need for application level code to opt-in to subclassing while still making external API contracts explicit and therefore hopefully more robust.  It is the default most in-line with the values and goals of Swift.
>> 
>> 'final' and 'sealed' are two very different things.  Let's please keep this focused on what is actually being proposed.
>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>