Non-null objects, the Null Object pattern, and T.init

[Ola Fosheim Grøstad" <ola.fosheim.grostad+dlang at gmail.com>]

On Monday, 20 January 2014 at 19:27:31 UTC, Walter Bright wrote:
> I infer you think that my arguments here are based on something 
> I dreamed up in 5 minutes of tip-tapping at my keyboard. They 
> are not. They are what Boeing and the aviation industry use 
> extremely successfully to create incredibly safe airliners, and 
> the track record is there for anyone to see.

No, but I think you are conflating narrow domains with a given 
practice and broader programming application development needs 
and I wonder what the relevance is to this discussion of having 
other options than bailing out. I assume that you were making a 
point that is of relevance to application programmers?? I assume 
that there is more to this than an anecdote?

And… no it is not ok to say that one should accept a buggy 
program to be in a inconsistent state until the symptoms surface 
and only then do a headshot, which is the reasoning behind 
one-buggy-implementation-running-until-null-crash. "you aren't 
ill until you look ill"?

But that is not what Boeing does, is it? Because they use a 
comparator: "we may be ill, but we are unlikely to show the same 
symptoms, so if we agree we assume that we are well." Which is a 
much more acceptable "excuse" (in terms of probability of 
damage). Why? Because a 0.001% chance of implementation related 
failure could be reduced to say 0.000000001% (depending on the 
resolution of the output etc).

Ideally safe-D should conceptually give you isolates so that an 
application can call a third party library that loads a corrupted 
file and crash on a null-ptr (because that code path has never 
been run before) and you catch that crash and continue. Yes, the 
library is buggy and only handles consistent files well, but as 
an application programmer that is fine. I only want to 
successfully load non-corrupt files, there is no need to fix that 
library. Iff the library/language assures that it behaves like it 
is run as an isolate (no side effects on the rest of the 
program). Wasting resources on handling corrupt files gracefully 
is pointless if you can isolate and contain the problem.

It is fine if HALT is the default in D, defaults should be 
conservative. It is not fine if the attitude is that HALT is the 
best option if the programmer thinks otherwise and anticipates 
trouble.