Null references redux

[Ary Borenszweig]

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. ;-)