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 ;-)