null and type safety

[Walter Bright]

Jarrett Billingsley wrote:
> 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.
> }

I don't see what you've gained here. The compiler certainly can do flow 
analysis in some cases to know that a pointer isn't null, but that isn't 
generalizable. If a function takes a pointer parameter, no flow analysis 
will tell you if it is null or not.