null and type safety

[Bill Baxter]

On Wed, Nov 5, 2008 at 10:43 PM, Jarrett Billingsley
<jarrett.billingsley at gmail.com> wrote:
> On Wed, Nov 5, 2008 at 3:18 AM, Walter Bright
> <newshound1 at digitalmars.com> wrote:
>> Jarrett Billingsley wrote:
>>> 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.
>>
>
> What?  Is your response in response to my post at all?  I am not
> talking about flow analysis on "normal" pointer types.  I am talking
> about the typing system actually being modified to allow a programmer
> to express the idea, with a _type_, and not with static checking, that
> a reference/pointer value _may not be null_.
>
> In a type system with non-null types, if a function takes a non-null
> parameter and you pass it a nullable pointer, _you get an error at
> compile time_.
>
> // foo takes a non-null int*.
> void foo(int* x) { writefln("%s", *x); }
>
> // bar returns a nullable int* - an int*?.
> int*? bar(int x) { if(x < 10) return new int(x); else return null; }
>
> foo(bar(3)); // compiler error, you can't pass a potentially null type
> into a parameter that can't be null, moron
>
> if(auto p = bar(3))
>    foo(p); // ok
> else
>    throw new Exception("Wah wah wah bar returned null");
>
> With nullable types, flow analysis doesn't have to be done.  It is
> implicit in the types.  It is mangled into function names.  foo
> _cannot_ take a pointer that may be null.  End of story.

I didn't really get what you meant the first time either.  The thing
about Delight's use of auto "to great effect" wasn't clear.   I
assumed it was basically the same as D's auto inside an if, but I see
now that it's not.  Looks like a run-time type deduction, even though
its not really.  Kinda neat.

--bb