Null references redux

[Steven Schveighoffer]

On Mon, 28 Sep 2009 15:35:07 -0400, Jesse Phillips  
<jesse.k.phillips+d at gmail.com> wrote:

> language_fan Wrote:
>
>> Have you ever used functional languages? When you develop in Haskell or
>> SML, how often you feel there is a good change something will be
>> initialized to the wrong value? Can you show some statistics that show
>> how unsafe this practice is?
>
> So isn't that the question? Does/can "default" (by human or machine)  
> initialization create an incorrect state? If it does, do we continue to  
> work as if nothing was wrong or crash? I don't know how often the  
> initialization would be incorrect, but I don't think Walter is concerned  
> with it's frequency, but that it is possible.

It creates an invalid, non-compiling program.

It's simple:

If initialization doesn't make sense, don't use non-nullable type.

If initialization makes sense, use non-nullable type, initialize with the  
correct value.

In case 1, we are back to current behavior, no problem (in Walter's eyes).

In case 2, we eliminate any possible crash due to non-initialization.

The subtle difference is the *default*.  If non-null is the default, then  
you haphazardly write code like this:

Object o;

And you get a compile error "error, please initialize o or declare as  
Object? o".  It makes you look at the line and say "hm... does it make  
sense to initialize there?" and you either put an initializer or you  
change it to

Object? o;

And move on.

90% of the time, you write something like:

auto x = new Object();

and you don't even have to think about it.  The compiler tells you when  
you got it wrong, and usually you then get it right after a moment of  
thought.

At least, that has been my experience with C# (granted, it uses flow  
analysis, not non-nullable defaults).  And I very seldom have null  
exception errors in my C# programs (they do happen, but of course, I get a  
nice stack trace).  Compare that to D, where I build my program and get:

# ./program_that_I_just_spent_1_week_writing_and_getting_to_compile
Segmentation fault.
#

I'd rather spend an extra 5 minutes having D compiler complain about  
initialization than face the Segmentation fault error search.

The thing is, I don't want D to cater to the moronic programmers that say  
"what? I need to initialize, ok, um.. here's a dummy object".  I want it  
to cater to *me* and prevent *me* from making simple errors where I  
obviously should have known better, but accidentally left out the  
initializer.

It's like the whole allowing object == null problem (coincidentally,  
resulting in the same dreaded error).  Once Walter implemented the  
compiler that flagged them all, he discovered Phobos had several of those  
*obviously incorrect* statements.  Hm... maybe he should do the same with  
this...  Maybe someone who can hack the compiler can do it for him!  Any  
takers?

-Steve

P.S.  I never make the object == null mistake anymore.  The compiler has  
trained me :)