References in D

[David Piepgrass]

> void main()
> {
> 	void* x = a(b());
> 	c();
> 	while(goobledegook)
> 	{
> 		x = p();
> 		d(x);
> 	}
> 	e(x); /+ Crash! x is null. +/
> }
>
> Where did x's null value come from?  Not a. Not p; the while 
> loop happened to be never executed.  To say "b" would be 
> closer, but still imprecise.  Actually it was created in the 
> q() function that was called by u() that was called by b() 
> which then created a class that held the null value and was 
> passed to a() that then dereferenced the class and returned the 
> value stored in the class that happened to be null.  nulls 
> create very non-local bugs, and that's why they frustrate me to 
> no end sometimes.

Since this thread's attracted lots of commotion I thought I'd 
just drop by and +1 for non-nullable types, and +1 for your 
arguments.

I keep wondering, though, if it is 'enough' to solve the null 
problem, or if it would be possible to devise a more general 
mechanism for solving other problems too, like say, the fact that 
certain integers have to always be positive, or if you want to go 
more general, that a certain relationship must hold between two 
structures...

Not having used D's invariants so far (well, I haven't used D 
itself for a real project actually)... what's stopping D's 
invariant mechanism from handling all this?

http://dlang.org/class.html#invariants (as is typical of D 
documentation, this says nothing about invariants on structs, but 
the page about structs says that they support invariants with an 
X.)

I mean, problems are detected at runtime this way, and slightly 
too late, but still, it would be better than most popular 
languages that can't do anything about nulls at all. Since D's 
devs don't even seem to have enough time to implement D as 
described in TDPL (published more than two years ago), I wouldn't 
expect to see this feature in the D language in the near future.