Null references redux

[Ary Borenszweig]

Jeremie Pelletier wrote:
> 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 :)

Ah, nice one.

Well, I see you can always break the type system. The point is to break 
it as little as possible while obtaining the most out of it without it 
bothering you.