Null references redux

[Nick Sabalausky]

"Walter Bright" <newshound1 at digitalmars.com> wrote in message 
news:h9mekt$160g$1 at digitalmars.com...
> language_fan wrote:
>> The idea behind non-nullable types and other contracts is to catch these 
>> errors on compile time. Sure, the code is a bit harder to write, but it 
>> is safe and never segfaults. The idea is to minimize the amount of 
>> runtime errors of all sorts. That's also how other features of statically 
>> typed languages work.
>
>
> I certainly agree that catching errors at compile time is preferable by 
> far. Where I disagree is the notion that non-nullable types achieve this. 
> I've argued extensively here that they hide errors, not fix them.
>

*IF* nullable types are completely disallowed, then yes, using non-nullables 
exclusively would probably lead to hacks that create subtle corruption. But 
that doesn't matter because nobody here is arguing for that.

What is being argued for is for non-nullables to supplement nullables. In 
this scenario, things like the 
DesignatedNullObjectThatsNotActuallyNullToShutUpTheCompiler don't remotely 
enter into the picture (or at least no moreso than they do already). What 
happens instead is simply that the programmer is now allowed to say "Hey 
compiler, this code doesn't deal with the possibility of a null on this 
param, so don't let anyone pass in something that could be null...that way 
it'll never corrupt *and* never crash." That's all it is. No error that was 
previously non-hidden becomes hidden here.

Of course, there is still one other requirement to pull this off without 
risking encouragement of those FakeNull objects (which I agree can hide 
errors, although we should remember they're still a real possibility even 
the way D currently is). We'd need a basic ability to track potential 
null-ness at compile-time, so that actually getting values into those 
non-nullables wouldn't be hindered. That is getting towards 
uninitialized-value-tracking, but that's a direction we really should be 
headed anyway (it really does work great in C# with very, very simple rules, 
no holy-grain needed...in fact, lack of holy-grail is preferable, but I've 
already made that argument weeks ago).

> Also, by "safe" I presume you mean "memory safe" which means free of 
> memory corruption. Null pointer exceptions are memory safe. A null pointer 
> could be caused by memory corruption, but it cannot *cause* memory 
> corruption.

No, he's using the real meaning of "safe", not the misleadingly-limited 
"SafeD" version of "safe" (which I'm still convinced is going to get some 
poor soul into serious trouble from mistakingly thinking their SafeD program 
is much safer than it really is). Out here in reality, "safe" also means a 
lack of ability to crash, or at least some level of protection against it. 
You seem to be under the impression that nothing can be made uncrashable 
without introducing the possibility of corrupted state. That's hogwash.