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

[Johan Engelen via Digitalmars-d-learn]

On Wednesday, 21 November 2018 at 09:31:41 UTC, Patrick Schluter 
wrote:
On Tuesday, 20 November 2018 at 23:14:27 UTC, Johan Engelen 
wrote:
On Tuesday, 20 November 2018 at 19:11:46 UTC, Steven 
Schveighoffer wrote:
On 11/20/18 1:04 PM, Johan Engelen wrote:

D does not make dereferencing on class objects explicit, 
which makes it harder to see where the dereference is 
happening.

Again, the terms are confusing. You just said the dereference 
happens at a.foo(), right? I would consider the dereference 
to happen when the object's data is used. i.e. when you read 
or write what the pointer points at.

But `a.foo()` is already using the object's data: it is 
accessing a function of the object and calling it. Whether it 
is a virtual function, or a final function, that shouldn't 
matter.

It matters a lot. A virtual function is a pointer that is in 
the instance, so there is a derefernce of the this pointer to 
get the address of the function.
For a final function, the address of the function is known at 
compile time and no dereferencing is necessary.

That is a thing that a lot of people do not get, a member 
function and a plain  function are basically the same thing. 
What distinguishes them, is their mangled name. You can call a 
non virtual member function from an assembly source if you know 
the symbol name.
UFCS uses this fact, that member function and plain function 
are indistinguishable in a object code point of view, to fake 
member functions.

This and the rest of your email is exactly the kind of thinking 
that I oppose where language semantics and compiler 
implementation are being mixed. I don't think it's possible to 
write an optimizing compiler where that way of reasoning works. 
So D doesn't do that, and we have to treat language semantics 
separate from implementation details.  (virtual functions don't 
have to be implemented using vtables, local variables don't have 
to be on a stack, "a+b" does not need to result in a CPU add 
instruction, "foo()" does not need to result in a CPU procedure 
call instruction, etc, etc, etc. D is not a portable assembly 
language.)

-Johan