What's the current state of D?

Michiel Helvensteijn m.helvensteijn.remove at gmail.com
Sun May 10 10:01:37 PDT 2009

It seems I didn't explain myself very clearly.

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

You need control-flow analysis to know at compile-time if:
* an uninitialized value is read, or
* a null pointer is dereferenced.

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

I understand the issue. In my idea, there are non-nullable pointers. In
fact, they would probably be the default kind of pointer. But Christopher
explained those kinds of pointers have their own problems. How to
initialize an array of non-nullables? Or a struct?

So formally introduce the notion of `uninitialized' variables, or in
particular, pointers. No need to initialize (even non-nullables) right
away. Just initialize anytime. I believe in D you specify this with =void.

But don't you see, you've replaced your null-dereference problem with a
uninitialized-reading problem. That's basically the same deal.

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

Exactly. This brings me back to the need for rigorous control-flow analysis.
Without it, you can't get your info at compile-time in the general case.

Michiel Helvensteijn

More information about the Digitalmars-d mailing list