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

[L. Mihalkovic]

Regards
(From mobile)

On Jul 10, 2016, at 12:01 AM, Károly Lőrentey via swift-evolution <swift-evolution at swift.org> wrote:

>> On 2016. Jul 9., at 22:55, Goffredo Marocchi <panajev at gmail.com> wrote:
>> 
>> Why have they not "fixed" this issue with Java 6/7/8 if it is bad to have the current setup by default? Why C++ x09/x11/x14 is also not making everything sealed/unsubclassable by default?
> 
> I'd wager a guess that the strong desire not to break source compatibility with existing code explains why Java and C++ are stuck forever with suboptimal defaults.

May I suggest that you might want to read about it if you have any interest in making accurate statements about it.

> Some members of this list have a bit of background in C++ language design (understatement of the day!); perhaps they know more.
> 
>> Is it possible that having library authors use something like a sealed keyword or similar is good enough for the default case?
> 
> Swift is to be safe by default. I believe open subclassability is a power tool that's unsafe without adequate training and thick protective gear; therefore, it is useful to require posting yellow/black hazard signs when it is in use. Safety first.
> 
> "Opting for safety sometimes means Swift will feel strict, but we believe that clarity saves time in the long run."

It each their own... some people like the mental comfort of others building safeguard for them, others like to live baring the full weight of the consequences of their choices. Nothing wrong, just two different approaches to life.


> 
> Karoly
> @lorentey
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution