On Sun, 27 Sep 2009 01:08:32 +0400, Walter Bright
<[email protected]> wrote:
Denis Koroskin wrote:
> On Sat, 26 Sep 2009 22:30:58 +0400, Walter Bright
> <[email protected]> wrote:
>> D has borrowed ideas from many different languages. The trick is to
>> take the good stuff and avoid their mistakes <g>.
>
> How about this one:
>
http://sadekdrobi.com/2008/12/22/null-references-the-billion-dollar-mistake/
>
>
> :)
I think he's wrong.
Getting rid of null references is like solving the problem of dead
canaries in the coal mines by replacing them with stuffed toys.
It all depends on what you prefer a program to do when it encounters a
program bug:
1. Immediately stop and produce an indication that the program failed
2. Soldier on and silently produce garbage output
I prefer (1).
Consider the humble int. There is no invalid value such that referencing
the invalid value will cause a seg fault. One case is an uninitialized
int is set to garbage, and erratic results follow. Another is that (in
D) ints are default initialized to 0. 0 may or may not be what the logic
of the program requires, and if it isn't, again, silently bad results
follow.
Consider also the NaN value that floats are default initialized to. This
has the nice characteristic of you know your results are bad if they are
NaN. But it has the bad characteristic that you don't know where the NaN
came from. Don corrected this by submitting a patch that enables the
program to throw an exception upon trying to use a NaN. Then, you know
exactly where your program went wrong.
It is exactly analogous to a null pointer exception. And it's darned
useful.
I don't understand you. You say you prefer 1, but describe the path D
currently takes, which is 2!
dchar d; // not initialized
writeln(d); // Soldier on and silently produce garbage output
I don't see at all how is it related to a non-null default.
Non-null default is all about avoiding erroneous situations, enforcing
program correctness and stability. You solve an entire class of problem:
NullPointerException.
