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
