References in D

Henning Pohl henning at still-hidden.de
Wed Oct 3 11:07:04 PDT 2012


On Wednesday, 3 October 2012 at 17:37:14 UTC, Franciszek Czekała 
wrote:
> 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?
You have to decide which information should be available at 
compile- and runtime. And that is not easy. In general, it's 
always better to have information present at compile time. To 
come back to your example:

class Number {
     this(int i) {
         this.i = i;
     }

     const int i;
}

class PrimeNumber : Number {
     this(int i) {
         // Check whether i is a prime number or not...
         ....

         super(i);
     }
}

void func(PrimeNumber num);

That's a way to check this at compile time and pass the number 
without runtime checks between prime number functions. But it 
requires i to be constant throughout the lifetime of Number.

It always depends on the context if the use of an extra class 
makes 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
Great, use a question mark.

> 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.
Contract programming comes into play. But still, you have to 
write contracts containing all those assertions. In libraries you 
can't even use contracts in most cases.

> 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?
If you write an application, indeed, it's easy to fix.

> To quote (loosely) Mr. Walter Bright from another discussion: 
> how many current bugs in dmd are related to default null 
> references?
DMD is an application, not a library.




More information about the Digitalmars-d mailing list