What's the current state of D?

[Michiel Helvensteijn]

Christopher Wright wrote:

>> About the null references, most people seem to agree that the right way
>> to fix that is with some sort of "non-nullable". But there's a lot of
>> disagreement on exactly how non-nullables should work.
> 
> And whether they *can* work. D2 has struct constructors, so structs can
> have non-nullable fields, but you can't have an array of non-nullable
> elements (you can set the length, and suddenly your non-nullable-element
> array has a bunch of nulls in it). Similarly, no arrays of structs
> containing non-nullable types, etc.

The point of non-nullables would be to detect improper usage at
compile-time, right? Then I don't believe this problem has an elegant
solution until compilers can do a rigorous control-flow analysis.
Specifying default pointer values other than null doesn't seem very nice.

Nonetheless, a good step forward would be to recognize the distinction
between `null' and `uninitialized'. Reading a variable that's uninitialized
is an error. Reading a null pointer is fine, but dereferencing it is an
error.

This effectively solves your non-nullable problems, but you'd basically be
replacing them with another problem. In general, you can only know if a
variable is initialized at run-time. And then only if you reserve memory
for the `uninitialized' state.

So effectively, what's the difference between that and the original null
reference problem? You'd basically get the runtime error when you read the
pointer, but before you dereference it.

Until compilers are smart enough.

-- 
Michiel Helvensteijn