<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">&lt;<a href="mailto:karoly@lorentey.hu" target="_blank">karoly@lorentey.hu</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
&gt; On 2016. Jul 9., at 22:55, Goffredo Marocchi &lt;<a href="mailto:panajev@gmail.com">panajev@gmail.com</a>&gt; wrote:<br>
&gt;<br>
&gt; Why have they not &quot;fixed&quot; 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&#39;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>
&gt; 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&#39;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>
&quot;Opting for safety sometimes means Swift will feel strict, but we believe that clarity saves time in the long run.&quot;<br>
<br>
Karoly<br>
@lorentey<br>
</blockquote></div><br></div>