References in D

[Franciszek Czekała" <home at valentimex.com>]

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.