References in D

[Franciszek Czekała" <home at valentimex.com>]

On Wednesday, 3 October 2012 at 16:33:15 UTC, Simen Kjaeraas 
wrote:
> On 2012-10-03, 18:12,  wrote:
>

> They make sure you never pass null to a function that doesn't 
> expect null - I'd say that's a nice advantage.

No, it is meaningless. If you have a class which is supposed to 
hold a prime number and you pass it to a function are you going 
to check each time that the value is indeed prime? That would 
kill the efficiency of your program guaranteed. So you would be 
happy to know that the reference is non-null but you would take 
it for granted the value is indeed prime? Does it make any sense?
I maintain that this non-null "advantage" does not warrant to 
make the language more complicated even by a tiny bit. It is 
dwarfed by normal considerations related to program correctness.

With default null references:
A)either null is an expected non-value for the type (like in the 
chess example), checking for it is part of normal processing then
B) or null is not a valid value, then there is no need to check 
for it. If you get a null reference it is a bug. It is like 
getting a 15 for your prime number. You do not put checks like 
that in your code. You test your prime generation routine not the 
consumers. If your function gets a null reference when it should 
not, some other part of your program is buggy. You do not process 
bugs in your code - you remove them from it.

However with D, dereferencing an uninitialized reference is well 
defined - null is not random data: you get a well-defined 
exception and you know you are dealing with unitialized data. 
This is easy to fix. You just go up the stack and check where the 
reference comes from. Much easier probably than finding out why 
your prime numbers turn out to be divisible by 3. How about 
introducing some syntax that will rule this out?

To quote (loosely) Mr. Walter Bright from another discussion: how 
many current bugs in dmd are related to default null references?