null and type safety

[Jarrett Billingsley]

On Tue, Nov 4, 2008 at 11:40 PM, Walter Bright
<newshound1 at digitalmars.com> wrote:
> I understand your point, and it sounds right technically. But practically,
> I'm not convinced.
>
> For example, consider a linked list. How do you know you've reached the end
> of the list? By the pointer being null or pointing to some "impossible"
> object. If you pick the latter, what really have you gained over a null
> pointer?
>

The implication of non-nullable types isn't that nullable types
disappear; quite the opposite, in fact.  Nullable types have obvious
use for exactly the reason you explain.  The problem arises when
nullable types are used in situations where it makes _no sense_ for
null to appear.  This is where bugs show up.  In a system that has
both nullable and non-null types, nullable types act as a sort of
container, preventing you from accessing anything through them as it
cannot be statically proven that the access will be legal at runtime.
In order to access something from a nullable type, you have to convert
it to a non-null type.  Delight uses D's "declare a variable in the
condition of an if or while" to great effect here:

if(auto f = someFuncThatReturnsNullableFoo()) // f is declared as non-null
{
    // f is known not to be null.
}
else
{
    // something else happened.  Handle it.
}

Null still has a purpose.  It's just that its purpose is really only
to signal a special case.