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

Johan Engelen j at j.nl
Tue Nov 20 23:14:27 UTC 2018


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. There are 
different ways of implementing class function calls, but here 
often people seem to pin things down to one specific way. I feel 
I stand alone in the D community in treating the language in this 
abstract sense (like C and C++ do, other languages I don't know). 
It's similar to that people think that local variables and the 
function return address are put on a stack; even though that is 
just an implementation detail that is free to be changed (and 
does often change: local variables are regularly _not_ stored on 
the stack [*]).

Optimization isn't allowed to change behavior of a program, yet 
already simple dead-code-elimination would when null dereference 
is not treated as UB or when it is not guarded by a null check. 
Here is an example of code that also does what you call a 
"dereference" (read object data member):
```
class A {
     int i;
     final void foo() {
         int a = i; // no crash with -O
     }
}

void main() {
     A a;
     a.foo();  // dereference happens
}
```

When you don't call `a.foo()` a dereference, you basically say 
that `this` is allowed to be `null` inside a class member 
function. (and then it'd have to be normal to do `if (this) ...` 
inside class member functions...)

These discussions are hard to do on a mailinglist, so I'll stop 
here. Until next time at DConf, I suppose... ;-)

-Johan

[*] intentionally didn't say where those local variables _are_ 
stored, so that people can solve that little puzzle for 
themselves ;-)



More information about the Digitalmars-d-learn mailing list