References in D

[bearophile]

Franciszek Czekała:

> 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.

Surely there are more important things to care about. But a 
non-null system has right the purpose of allowing you to take 
more care of the program logic and less about possible null 
values.


> 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

A well implemented not-nullable system forces you to verify the 
possible presence of null of nullable values. And if you handle 
the null value in a "if" clause then the compiler will assume the 
reference is not null in the other clause. This essentially means 
the type of that reference is different inside the two clauses.

A small program that shows two or three important things 
std.typecons.Nullable isn't able to do:


import std.stdio, std.algorithm, std.typecons;

alias Nullable!(int, -1) Position;

void foo(int[] a, Position pos) /*nothrow*/ { // allow this to be 
nothrow
     if (pos.isNull) {
         return;
     } else {
         a[pos] = 10; // perform no nullness test here, 
optimization
     }
}

void bar(int[] a, Position pos) {
     a[pos] = 10; // maybe: require a test here?
}

void main() {
     auto data = [1, 2, 3, 4, 5];
     auto p = Position(countUntil(data, 7));
     foo(data, p);
     writeln(data);
}


> 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.

Even better: avoid similar problems statically, with a 
not-nullable extension of the type system, so there is no need to 
debug your program after a run.


> 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?

If D programs contain prime number classes as often as not-null 
references then adding a syntax to statically rule out not-prime 
numbers is an acceptable idea. But the initial assumption is 
false. Walter&Andrei have added @disable to try to allow 
programmers to disallow the presence of divisible numbers inside 
instances of a prime class too. But I am not sure the final 
result is good enough.


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

DMD source code is a compiler, it's not representative of all 
kinds of D programs. I think there is a class of commercial 
programs, or pointer-heavy programs that enjoy having not-null 
references.

Even if null-related bugs are not common in D code, having a 
language help you reduce one class of bugs helps you program 
faster. I am sometimes able to write working (and almost 
"correct") C programs, but D safeties allows me to write them 
faster. If you ask to Scala programmers they will tell you they 
are quite happy to not have to worry much about nulls when they 
write idiomatic Scala code, while they will tell you they have to 
keep more care when they inter-operate with Java code that 
sometimes has nulls.

Bye,
bearophile