Null references

bearophile bearophileHUGS at lycos.com
Tue Aug 21 13:48:11 PDT 2012


Regan Heath:

> Plus, I don't buy the argument that having to explicitly type 
> ".get" will stop anyone from automatically coding statements 
> like:
>
> val g: Option[T] = f.doSomething()
> g.get.doSomethingElse()
>
> and suffering the exact same null pointer exception/error 
> despite using Option and boxing into a Not-Null type.
>
> Like checked exceptions people will simply ignore the 
> possibility of error and type the above anyway.  So, end 
> result, it's just more typing for no real gain.

Mark C. Chu-Carroll is very intelligent and well read, most times 
he's right. My Scala experience is limited, so I don't first-hand 
how much Mark is right this time.

I think having a type for a reference/pointer that can't be null 
is useful. With it in many situations you need no "get", because 
there no risk of it being null. So the discussion here is for the 
other cases where you need a reference that can be null too. Such 
cases are surely just part of the cases where in D now you 
receive a generic nullable reference/pointer. So even if "get" is 
about as dangerous as normal references, the situation is better 
still.

Time ago I have suggested a syntax like Foo@ to represent in D 
the subtype of Foo references that can't be null.

Bye,
bearophile


More information about the Digitalmars-d mailing list