Null references redux

[Jeremie Pelletier]

Derek Parnell wrote:
> On Mon, 28 Sep 2009 19:27:03 -0500, Andrei Alexandrescu wrote:
> 
>> language_fan wrote:
>>>   int min;
>>>
>>>   foreach(int value; list)
>>>     if (value < min) min = value;
>>>
>>> Oops, you forgot to define a flag variable or initialize to int.min
>> You mean int.max :o).
> 
>   if (list.length == 0)
>      throw( some exception); // An empty or null list has no minimum
>   int min = list[0]; 
>   foreach(int value; list[1..$])
>     if (value < min) min = value;
> 
> 
> I'm still surprised by Walter's stance.
> 
> For the purposes of this discussion...
> * Null only applies to the memory address portion of reference types and
> not to value types. The discussion is not about non-nullable value types.
> * There are two types of reference types:
>   (1) Those that can be initialized on declaration because the coder knows
> what to initialize them to; a.k.a. non-nullable. If the coder does not know
> what to initialize them to at declaration time, then either the design is
> wrong, the coder doesn't understand the algorithm or application, or it is
> truly a complex run-time decision.
>   (2) Those that aren't in set (1); a.k.a. nullable.
> * The standard declaration should imply non-nullable. And if not
> initialized the compiler should complain. This encourages protection, but
> does not guarantee it, of course.
> * To declare a nullable type, use a special syntax to denote that the coder
> is deliberately choosing to declare a nullable reference.
> * The compiler will prevent non-nullable types being simply set to null. As
> D is a system language too, there will be a rare cases that need to subvert
> this compiler protection, so there will need to be a method to explicitly
> set a non-nullable type to a null. The point is that such a method should
> be a visible warning beacon to maintenance coders.
> 
> Priority should be given to coders that prefer safe coding. If a coder, for
> whatever reason, chooses to use nullable references or initialize
> non-nullable reference to rubbish data, then the responsibility is on them
> to ensure safe applications. Safe coding practices should not be penalized.
> 
> The C/C++ programming language is inherently "unsafe" in this regard, and
> that is not news to anyone. The D programming language does not have to
> follow this paradigm.

But it doesn't have to follow the paranoid safety paradigm either. I 
wouldn't like two reference types and casting between the two when 
they're essentially the same with one having a single value that can't 
be set out of 4 billions possibilities. Seems like a waste to me, 
especially since 3 billions of these possibilities will result in the 
same segfault crash than that one you're trying to make illegal on 
nonnull types.

> I'm still not ready to use D for anything, but I watch it in hope.

I'm already using D quite a lot, I don't find null vs nonnull references 
all that meaningful. Like walter said, you can just make your own 
nonnull invariant.

Here's a very, very simple wrapper, took 10 seconds to write:

struct NonNull(C) if(is(C == class)) {
	C ref;
	invariant() { assert(ref !is null); }
	T opDot() { return ref; }
}

C++ has all sort of pointer wrappers like this one, you don't see a 
smart pointer feature in the C++ language for the simple reason its 
widely used and safer. In fact letting the semantics of these pointers 
up to libraries allow any project to write its custom ones, and quite a 
lot do.

It should be the same for D, I believe its better to implement flow 
analysis and let the compiler warn you of uninitialized variables (which 
will solve most nullptr references, the other half being by 
NonNull!Object fields). The compiler could also provide better tools to 
build smart wrapper types upon (like force initialization or prevent 
void initialization, heck even provide a tuple of valid initializers) 
and let libraries write their own.

Jeremie