System programming in D (Was: The God Language)

[Walter Bright]

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.