Nullable types

[Bruce Adams]

On Mon, 20 Oct 2008 08:34:30 +0100, Lionello Lunesu  
<lionello at lunesu.remove.com> wrote:

> Hi,
>
> I'm getting more and more intrigued by the way Delight [1] and F# [2]  
> handle nullable types: using the type-system to check for "nullness" the  
> way it does for constness*. I haven't used either one of those two  
> languages, but since having read about both systems, I can't help  
> keeping a tag in my mind for each variable; "this one can be null",  
> "this one can't be null"...
>
> * Is there anybody with experience using this concept of nullness in F#  
> or Delight?
>
> * Are there any other languages with this concept?
>
> * I personally think it would be nice for D too. Your opinions?
>
> L.
>
> PS. I have the feeling this also can be generalized, like the  
> green-code-red-code system. It's like a compile-time tagging of  
> variables, with some added syntactic sugar (the ?-token).
>
> [1] http://delight.sourceforge.net/null.html
> [2]  
> http://research.microsoft.com/fsharp/manual/import-interop.aspx#Nullness

In C++ I've always used a very simply rule.
If it can possibly be null use a pointer.
If it should never be null use a reference.

In languages like Java where there is no such distinction life is  
difficult.
Of course you can still (I find its quite rare) have null references.
This indicates a programming error and is usually caused by the ground  
shifting
under your feet. For example append to a std::vector and it may need to be
re-allocated in order to accomodate it, which will invalidate any previous  
references.
This is another place where invariant would come in handy. A reference to  
an invariant
can never be invalidated.
I'm not sure how this pattern can be applied in D, as it seem to follow  
the Java mould
mixing the semantics of pointers and references. (disclaimer: I haven't  
been doing much D programming lately)

Regards,

Bruce.