Why does nobody seem to think that `null` is a serious problem in D?

[Neia Neutuladh]

On Wed, 21 Nov 2018 20:15:42 +0000, welkam wrote:
> In D classes are reference type and unless you mark them as final they
> will have vtable.

Even if you mark your class as final, it has a vtable because it inherits 
from Object, which has virtual functions. The ProtoObject proposal is for a 
base class that has no member functions. If you had a final class that 
inherited from ProtoObject instead of Object, it would have an empty 
vtable.

> Lets face it most people dont mark their classes as
> final. What all this mean is that EVERY access to class member value
> goes trough indirection (additional cost)

D classes support inheritance. They implicitly cast to their base types. 
They can add fields not present in their base types. If they were value 
types, this would mean you'd lose those fields when up-casting, and then 
you'd get memory corruption from calling virtual functions.

That is a cost that doesn't happen with structs, I'll grant, but the only 
way to avoid that cost is to give up inheritance. And inheritance is a 
large part of the reason to use classes instead of structs.

> and EVERY method call goes
> trough 2 indirections (one to get vtable and second to call
> function(method) from vtable).

Virtual functions do, that is. That's the vast majority of class member 
function calls.

> Now Java also have indirect vtable calls
> but it also have optimization passes that convert methods to final if
> they are not overridden. If Java didnt do that it would run as slow as
> Ruby.

Yeah, no.

https://git.ikeran.org/dhasenan/snippets/src/branch/master/virtualcalls/
results

Java and DMD both managed to de-virtualize and inline the function. DMD can 
do this in simple cases; Java can do this in a much wider range of cases 
but can make mistakes (and therefore has to insert guard code that will go 
back to the original bytecode when its hunches were wrong).

If it were merely devirtualization that were responsible for Java being 
faster than Ruby, Ruby might be ten times the duration of Java (just as 
dmd without optimizations is within times the duration of dmd without 
optimizations). You could also argue that `int += int` in Ruby is another 
virtual call, so it should be within twenty times the speed of Java.

Instead, it's 160 times slower than Java.

> On top of that some
> people want to check on EVERY dereference if pointer is not null. How
> slow you want your programs to run?

Every program on a modern CPU architecture and modern OS checks every 
pointer dereference to ensure the pointer isn't null. That's what a 
segfault is. Once you have virtual address space as a concept, this is 
free.

> Thats negatives but what benefit classes give us?
> First being reference type its easy to move them in memory. That would
> be nice for compacting GC but D doesnt have compacting GC.

You can do that with pointers, too. D doesn't do that because (a) it's 
difficult and we don't have the people required to make it work well 
enough, (b) it would make it harder to interface with other languages, (c) 
unions mean we would be unable to move some objects and people tend to be 
less thrilled about partial solutions than complete ones.

> Second they
> are useful for when you need to run code that some one else wrote for
> your project. Something like plugin system. [sarcasm]This is happening
> everyday[/sarcasm]
> Third porting code from Java to D.
> 
> Everything else you can do with struct and other D features.

Similarly, you can write Java-style object oriented code in C. It's 
hideously ugly and rather error-prone. Every project trying to do it would 
do it in a different and incompatible way.

Walter decided a long time ago that language support for Java-style OOP 
was a useful component for D to have, and having a standardized way of 
doing it with proper language support was better than leaving it to a 
library.