<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The thing I'm most worried about is people forgetting to declare 'final:' on a<br>
class, or junior programmers who DON'T declare final, perhaps because they don't<br>
understand it, or perhaps because they have 1-2 true-virtuals, and the rest are<br>
just defined in the same place... This is DANGEROUS.<br>
</blockquote>
<br>
It isn't dangerous, it is just less optimal. What is dangerous is (in C++) the ability to override a non-virtual function, and the use of non-virtual destructors.<br></blockquote><div><br></div><div>In 15 years I have never once overridden a non-virtual function, assuming it was virtual, and wondering why it didn't work... have you?</div>
<div>I've never even heard a story of a colleague, or even on the net of that ever happening (yes, I'm sure if I google specifically for it, I could find it, but it's never appeared is an article or such)... but I can point you at almost daily examples of junior programmers making silly mistakes that go un-noticed by their seniors. Especially common are mistakes in declaration where declaration attributes don't change whether the program builds and works or not.</div>
<div><br></div><div>It seems to me the decision is that of sacrificing a real and common problem case with frequent and tangible evidence, for the feeling that the language is defined to do the 'right' thing?</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It's also true that D's design makes it possible for a compiler to make direct calls if it is doing whole-program analysis and determines that there are no overrides of it.<br>

</blockquote></div><br><div>This is only possible with whole program optimisation, and some very crafty code that may or may not ever be implemented, and certainly isn't dependable from compiler vendor 'x'.. There would simply be no problem in the first place if the default was declared the other way around, and the compiler would need none of that extra code, and there are no problems of compiler maturity.</div>
<div>Surely this sort of consideration is even more important for an open source project with a relatively small team like D than it is even for C++?</div>