References in D

[Alex Burton]

On Friday, 5 October 2012 at 04:50:18 UTC, Jonathan M Davis wrote:
> On Friday, October 05, 2012 05:42:03 Alex Burton wrote:
>> I realise what is currently the case I am making an argument as
>> to why I this should be changed (at least for class references 
>> in
>> D).
>
> This was talking about C++ references, not D, giving an example 
> of how they
> can be null even though most people think that they can't be. 
> int& isn't even
> legal syntax in D.

I was talking about both. Regardless of whether the int& 
reference or the int * reference was used to assign to memory 
address 0 in Walters example the result is still a crash and will 
be in D with equivalent code using explicit pointers or instances 
of classes (which are always pointers in D).

The crash is a result of two mistakes:

One is the language designer allowing null to be an acceptable 
value for a pointer to an int.
As should be blatently obvious that null is not a pointer to an 
int, but for historical reasons inherited from C (when people 
were just happy to get out of assembly language) it has been 
allowed.

The second mistake is that someone chose to use the language 
feature which clearly makes no sense.
This is bad programming for two reasons:
1) It is logically incorrect to state that 0 is a pointer to 
something.
2) It is a case of using magic numbers in code - an antipattern. 
It is trying to create some universal consensus that the magic 
number 0 means something special. What I am supposed to do with a 
null pointer is not so universal.
Do I construct it ? Do I throw an exception ? Why on earth has 
someone sent me this 0 when my type system specifies I want a 
pointer to an int ?

> Regardless, references in D will _never_ be non-nullable. It 
> would break too
> much code to change it now regardless of whether nullable or 
> non-nullable is
> better.

I don't think this argument is any more powerful than any of the 
other 'lets remain compatible with C to avoid breakage' ones.

If it were changed there could be compiler errors for 
uninitialised references, and tests for null. These sorts of 
compile time errors are much more preferable than undefined 
behaviour in released code that crashes IMHO.

Alex