(non)nullable types

[Nick Sabalausky]

"Michel Fortin" <michel.fortin at michelf.com> wrote in message 
news:gn4pl9$1217$1 at digitalmars.com...
> On 2009-02-13 14:01:57 -0500, "Nick Sabalausky" <a at a.a> said:
>
>>> Or use an existing syntax:
>>>
>>> Foo? foo = ...;
>>> if (Foo value = foo) {
>>> // value is a local variable that is only accessible if foo is not
>>> null
>>> } else {
>>> // value is not accessible here
>>> }
>>
>> I could live with that, but I'd prefer my suggestion because it wouldn't
>> require the creation of an extra label for what's essentially the same
>> variable. With your code we'd just end up with a whole bunch of:
>>
>> Foo? myObj = ...;
>> if (Foo nonnullMyObj = myObj) //etc...
>>
>> // or
>>
>> Foo? nullableMyObj = ...;
>> if (Foo myObj = nullableMyObj) //etc...
>>
>> ...Which just seems unnecessary to me.
>
> Foo? myObj = ...;
> if (myObj !is null)
> {
>     doSomethingWith(myObj);
>     myObj = null; // should this be an error?
> }
>

--------
// This (a more generalized case of above)...

Foo? myObj = ...;
if(myObj !is null)
{
    bar1(myObj);
    if(blah1 > blah2)
        myObj = null; // Yes, error
    bar2();
}

// ...would change to this...

Foo? myObj = ...;
bool turnToNull=false;
if(myObj !is null)
{
    bar1(myObj);
    if(blah1 > blah2)
        turnToNull = true;
}
if(turnToNull)
{
    myObj = null;
    bar2();
}
--------

> And what about:
>
> Foo? myObj = ...;
> while (myObj !is null)
>     myObj = myObj.next;
>

--------
Foo? myObj = ...;
while(true)
{
    if(myObj.next !is null)
        myObj = myObj.next;
    else
        break;
}
myObj = null; //this line optional

// Or, if you don't like "while(true)",
// you could use a "bool done" flag.
--------

With Denis's syntax, I'm not sure how the second one would be possible, but 
the first one would certainly be nicer. So I'm tempted to say that both 
syntaxes should be allowed...

However, you do have a valid point that my syntax has a problem whenever 
assigning a possibly-null value to the original nullable variable from 
within the scope of the null-check. It can definitely be worked around, but 
I am coming to realize that maybe removing a variable's nullability 
shouldn't happen implicitly unless it can also be added back implicity - 
which would require flow analysis.

Between that and the difficultly of Denis's syntax handling that simple 
while loop example, I guess full-blown flow-analysis would be needed after 
all in order to realistically eliminate null reference errors on nullable 
types. Dang!