Null references redux

[Christopher Wright]

Walter Bright wrote:
> Andrei Alexandrescu wrote:
>> Walter Bright wrote:
>>> Even forcing an explicit initializer doesn't actually solve the 
>>> problem - my experience with such features is programmers simply 
>>> insert any old value to get the code to pass the compiler, even 
>>> programmers who know it's a bad idea do it anyway.
>>
>> I think you're starting to be wrong at the point where you don't 
>> realize that many bugs come from references that people have forgotten 
>> to initialize. Once you acknowledge those, you will start to realize 
>> that a reference that must compulsively be initialized is valuable.
> 
> The problem is it's worse to force people to provide an initializer. 

You aren't forcing them. They decide for themselves. They determine 
whether it's appropriate for a particular variable to be null.

You can achieve the same goal through contracts. However, this is much 
more verbose -- enough so that you'll only add these contracts when 
hunting down a bug. And if you have an array of things

> It isn't a theoretical problem with providing bad initializers just to 
> shut the compiler up. I have seen it in the wild every time some manager 
> required that code compile without warnings and the compiler warned 
> about no initializer.

C# requires that every variable be initialized before use. You know how 
often I get such an error? Maybe once for every 100 hours of coding. 
It's mainly for cases where I expect an integer to be initialized to 0 
and it's not. You know how often I provide a bad initializer to shut the 
compiler up? Never.

This is partially because C#'s compiler has good flow analysis. It's 
mostly because:
  - I declare variables where I use them, not beforehand.
  - I often declare variables via IDE commands -- I write the code to 
fetch or calculate a value and assign it to a variable that doesn't 
exist, and the IDE fills in the type and declares it in the correct place.
  - I usually don't have more than four or five local variables in a 
function (often no more than one or two). Out of 300KLOC, there are a 
few dozen functions that break this rule.

DMDFE functions are often long, complex, and have many local variables. 
I see how this would conflict with your coding style. You would have to 
add a few question marks for each function, and then you'd be done. 
DMDFE is ~60KLOC, but you could probably switch it over to this type 
system without structural changes to any function in a couple days.