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

[Matthew Johnson]

Sent from my iPad

> On Jul 9, 2016, at 8:31 AM, Goffredo Marocchi <panajev at gmail.com> wrote:
> 
> Ok, then I should ask you to consider what I said earlier and substitute "final by default" with "sealed by default" and if we have this sealed keyword not to make it the default. 
> Trust coders and people a bit more instead of resorting to more involved obligatory processes instead. Do we really need in this case to seal modules by default? Can we just have a keyword that the library author can use and express this intent explicitly?

Of course it can be done either way.  But there are significant ecosystem robustness advantages to making sealed the default and comparatively few downsides.  Most libraries are open source (so can be modified directly or via PR if necessary) and Apple would likely use sealed widely in any Swift native APIs even if it must be stated explicitly.  

Sealed is the Swiftiest default.  It makes public API contracts explicit.  This is safer, more robust and adds clarity (you don't need to wonder whether an API author intended to support external subclassing, does not want external subclassing but supports needs it internally, or simply hasn't given it any thought)

> 
> Usually, look at some countries like Italy in a legislative sense, when you attempt to regulate in a way that everything is kind of banned except what you explicitly allow you get more convoluted, complex, and nerve wrecking solutions than allowing everything except what you explicitly ban (reviewing it all over time of course).

I don't see how comparing the domains of programming language design and politics / economic regulation makes any sense at all.

> 
> Sent from my iPhone
> 
>> On 9 Jul 2016, at 13:36, Matthew Johnson <matthew at anandabits.com> wrote:
>> 
>> 
>> 
>> 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
>>