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
