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

[Károly Lőrentey]

> 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. 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."

Karoly
@lorentey