On Wednesday, 3 October 2012 at 10:41:34 UTC, Henning Pohl wrote:
On Wednesday, 3 October 2012 at 08:11:32 UTC, Franciszek
Czekała wrote:
Agreed. Nullable types are a feature not a bug. There is no
need to change it. Bugs occur when you do not know the
language rules and make assumptions instead. This can happen
whith any language and any rules. As to an example use of
nullable references: consider a board game (for example
chess). The boards has cells which can be empty or occupied.
Model this with an array of class objects representing
pieces. null reference means a cell is not occupied. If you
want to remove a piece from the board assign null to it and GC
will take care of the rest. Now, doing this with full objects
representing empty cells would require needless work to define
such "null" objects and would be wasteful of memory (typically
boards are sparsely populated). Now imagine a really big board
and every cell holding references to useless objects
simulating null references. It would not make sense. Saying
that null references are evil is just propaganda. Let's keep D
a sane language.
There is a related question at stackoverflow:
http://stackoverflow.com/questions/693325/non-nullable-reference-types
As you can see the "nullable references are great" guy has been
voted down.
I've written like 5k lines of code in D and never felt the need
of using null. C++'s std::shared_ptr has the same issue, but at
least it is called pointer.
The need of using null: Every type needs a default value. null
supplies it perfectly for all class types in D. And it makes
sense regardless of what stackoverflow self-appointed political
commisars want you to believe. Consider my board example: with
null standing for "empty cell" when a new board is created as an
array it is by default empty -> in a meaningful state (think of
games like Go, etc). And at any rate you are going to use a
property/function like IsEmpty to check for empty cells. Why
should it be a problem to implement it by comparing with null? If
anything, it has a chance of being faster than when some other
concrete reference is used. Without null references you will end
up defining "null" objects all over the place (and sometimes it
may just be impossible when all values are meaningful). Then you
will have to store them globally and compare everything with
these objects (named like NullBoard, NullPiece, NullPawn, etc,
etc because it is ah so much better than just using a single
keyword null) and if you forget your program will silently churn
out garbage. With plain null references at least you would get an
exception. I'd rather see an exception than have a program
running smoothly with nonsensical results. Like seeing pieces
vanishing because they are being captured with a "null" piece
which I forgot to test for being "null". Because, you know, you
will still have to test conditions in your program to make it
meaningful, except that it may be a lot more troublesome when
your program grows x2 in size because of all those "safety"
mechanisms.
