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

[Johan Engelen]

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