<div dir="ltr">Reposting Károl reply on this list.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jul 9, 2016 at 11:01 PM, Károly Lőrentey <span dir="ltr"><<a href="mailto:karoly@lorentey.hu" target="_blank">karoly@lorentey.hu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
> On 2016. Jul 9., at 22:55, Goffredo Marocchi <<a href="mailto:panajev@gmail.com">panajev@gmail.com</a>> wrote:<br>
><br>
> 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?<br>
<br>
</span>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.<br>
<span class=""><br>
> Is it possible that having library authors use something like a sealed keyword or similar is good enough for the default case?<br>
<br>
</span>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.<br>
<br>
"Opting for safety sometimes means Swift will feel strict, but we believe that clarity saves time in the long run."<br>
<br>
Karoly<br>
@lorentey<br>
</blockquote></div><br></div>