D - Unsafe and doomed

[Alex Burton]

On Sunday, 5 January 2014 at 00:05:46 UTC, Walter Bright wrote:
> On 1/4/2014 3:04 PM, deadalnix wrote:
>> On Saturday, 4 January 2014 at 22:06:13 UTC, Walter Bright 
>> wrote:
>>> I don't really understand your point. Null is not that 
>>> special.
>>>
>>> For example, you may want a constrained type:
>>>
>>> 1. a float guaranteed to be not NaN
>>> 2. a code point guaranteed to be a valid code point
>>> 3. a prime number guaranteed to be a prime number
>>> 4. a path+filename guaranteed to be well-formed according to 
>>> operating system
>>> rules
>>> 5. an SQL argument guaranteed to not contain an injection 
>>> attack
>>>
>>> The list is endless. Why is null special?

Null is special in this set of examples because all of the 
examples show sub classes of the original type.
Math operations on NaN are well defined and don't result in a 
crash.
All the others should result in an exception at some point.
Exceptions allow stack unwinding, which allows people to write 
code that doesn't leave things in undefined states in the event 
of an exception.
Like files half written, database transactions half done, and all 
sorts of hardware with state left in intermediate states.
It also allows the program to recover gracefully, and allow the 
user to save their work, and continue working etc, with only a 
slightly embarassing, and possibly descriptive for bug reporting 
message stating that a problem occured.
Dereferencing null on windows can result in stack unwind, but on 
linux etc it is segfault with no unwind.

Null is not a valid pointer value. People that are assuming all 
pointers can be null are essentially treating all pointers as:
union
{
PointerType pointer;
bool pointerIsValid;
};

This might be a perfectly valid thing to do, but it is 
exceptional in the above list and therefore I would assume 
requires a new type (and more keyboard typing:) ) than what 
should be the default case of non null pointers.
>>
>> Because it is an instant crash,
>
> Would things going on and a random thing happening randomly 
> later be better?
>
>> because it is not possible to make it safe
>> without runtime check,
>
>> a bugguy code that could have crashed will know behave
>> in random ways).
>
> Above it seems you were preferring it to fail in random ways 
> rather than instant and obvious seg fault :-) For the record, I 
> vastly prefer the instant seg fault.
>
Yes I think this is certainly easier to debug, but the user 
experience will be equivalent, and the reputational damage and 
bug report will be equivalent.