On 1/5/2012 1:13 AM, Manu wrote:
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?
Yes, I have. With a complex inheritance hierarchy, I was doing the optimization
thing and removing 'virtual' from members that didn't get overridden. Then, some
long time later, I'd add an override and forget to put the 'virtual' back on the
original.
Very strange behavior of my program would result.
Even worse, frankly I defy anyone to look at a complex C++ inheritance hierarchy
and say with certainty that you've verified that there are no overrides of
non-virtual functions in it.
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.
That is the case with overriding a non-virtual function - the compiler will
compile it anyway, and most of the time it will work. That's what makes it so
eeevil.
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?
The right thing should be the default.
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.
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.
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++?
I feel the correct decision was made. But regardless, there's no way to reverse
that decision, as it will break most every D program in existence, and be a HUGE
annoyance to everyone who has D code.
