References in D

[Simen Kjaeraas]

On 2012-56-03 14:10,  wrote:

> The need of using null: Every type needs a default value.

Good gods, are we not done with this strawman yet?

No, not all types need a default value. In fact, for some types, it is
much better that they don't.


> 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).

Yes, null is useful. Nobody is trying to take null away from you.

What we want is the ability to say 'this can never be null', so that we
don't need to check for null over and over.


> 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?

This is not what non-nullable references are about.

When not to use non-nullable references:
  - When the absence of a value is a valid value.
Example:
  - Chess board boxes.

When to use non-nullable references:
  - When the absence of a value is not a valid value.
Example:
  - RenderFoo(NotNull!Foo)


> 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).

No. Please read more about non-nullable references.


> 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.

This... Please... Please, just read more about the topic before
commenting. Please.

-- 
Simen