Null references redux

[Jeremie Pelletier]

Ary Borenszweig wrote:
> Jeremie Pelletier wrote:
>> Ary Borenszweig wrote:
>>> Walter Bright wrote:
>>>> Daniel Keep wrote:
>>>>> "But the user will just assign to something useless to get around 
>>>>> that!"
>>>>>
>>>>> You mean like how everyone wraps every call in try{...}catch(Exception
>>>>> e){} to shut the damn exceptions up?
>>>>
>>>> They do just that in Java because of the checked-exceptions thing. I 
>>>> have a reference to Bruce Eckel's essay on it somewhere in this 
>>>> thread. The observation in the article was it wasn't just moron 
>>>> idiot programmers doing this. It was the guru programmers doing it, 
>>>> all the while knowing it was the wrong thing to do. The end result 
>>>> was the feature actively created the very problems it was designed 
>>>> to prevent.
>>>>
>>>>
>>>>> Or uses pointer arithmetic and
>>>>> casts to get at those pesky private members?
>>>>
>>>> That's entirely different, because privacy is selected by the 
>>>> programmer, not the language. I don't have any issue with a 
>>>> user-defined type that is non-nullable (Andrei has designed a type 
>>>> constructor for that).
>>>>
>>>>
>>>>> If someone is actively trying to break the type system, it's their
>>>>> goddamn fault!  Honestly, I don't care about the hacks they employ to
>>>>> defeat the system because they're going to go around blindly shooting
>>>>> themselves in the foot no matter what they do.
>>>>
>>>> True, but it's still not a good idea to design a language feature 
>>>> that winds up, in reality, encouraging bad programming practice. It 
>>>> encourages bad practice in a way that is really, really hard to 
>>>> detect in a code review.
>>>>
>>>> I like programming mistakes to be obvious, not subtle. There's 
>>>> nothing subtle about a null pointer exception. There's plenty subtle 
>>>> about the wrong default value.
>>>>
>>>>
>>>>> And what about the people who AREN'T complete idiots, who maybe
>>>>> sometimes just accidentally trip and would quite welcome a safety rail
>>>>> there?
>>>>
>>>> Null pointer seg faults *are* a safety rail. They keep an errant 
>>>> program from causing further damage.
>>>
>>> Null pointer seg faults *not being able to happen* are much more 
>>> safe. :)
>>
>> There is no such thing as "not being able to happen" :)
>>
>> Object thisCannotPossiblyBeNullInAnyWayWhatsoever = cast(Object)null;
> 
> Object is not-nullable, Object? (or whatever syntax you like) is 
> nullable. So that line is a compile-time error: you can't cast a null to 
> an Object (because Object *can't* be null).
> 
> You might be the only one here that understands Walter's point. But 
> Walter is wrong. ;-)

union A {
	Object foo;
	Object? bar;
}

Give me a type system, and I will find backdoors :)

I didn't say Walter was right or wrong, I said I understand his point of 
view. The sweet spot most likely lie in the middle of both arguments 
seen in this thread, and that's not an easy one to pinpoint!

I think we should much rather enforce variable initialization in D than 
nullable/non-nullable types. The error after all is that an unitialized 
reference triggers a segfault.

What if using 'Object obj;' raises a warning "unitialized variable" and 
makes everyone wanting non-null references happy, and 'Object obj = 
null;' raises no warning and makes everyone wanting to keep the current 
system (all two of us!) happy.

I believe it's a fair compromise.