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