What's the current state of D?

[Daniel Keep]

Michiel Helvensteijn wrote:
> ...
> 
> 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.

You don't need control-flow analysis.  You just need a type system which
supports nullables like D2's supports const.

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

Uninitialised variables is only a symptom.  The larger issue is that it
doesn't make sense for most functions to accept null object arguments.
It's quite rare, at least in my code, to have a function that can do
anything sensible with "nothing" other than HCF [1].

> This effectively solves your non-nullable problems, but you'd basically be
> replacing them with another problem.

No, it doesn't.

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

The whole point of having non-nullable types is so that you can't even
STORE a null in the first place.  We already have a runtime check, and
it's not good enough.  The major issue is that it notifies us of a
problem at a time when we generally do not have any useful information
on how to solve it.

The problem isn't dereferencing nulls.  It's when they get STORED that's
the problem.

  -- Daniel


[1] HCF - Halt and Catch Fire; old instruction on the PDP machines. :P