(non)nullable types

[Denis Koroskin]

On Sat, 14 Feb 2009 15:42:57 +0300, Yigal Chripun <yigal100 at gmail.com> wrote:

> Denis Koroskin wrote:
>> On Sat, 14 Feb 2009 11:39:17 +0300, Nick Sabalausky <a at a.a> wrote:
>>
>>> "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)
>>
>> Dang! NullPointerException, because you never checked myObj against 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,
>>
>> Foo? myObj = ...;
>> if (Foo obj = myObj) {
>> while (true) {
>> if (auto next = obj.next) {
>> obj = next;
>> } else {
>> break;
>> }
>> }
>> }
>>
>>> 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!
>>>
>>
>> I don't think code flow analysis the way you suggest is useful. I
>> certainly don't want my variable types to be changed at some point after
>> null-check.
>>
>> Code flow analysis would be nice to have, but in a different way:
>>
>> Foo b; // not initialized, can not be read yet
>>
>> if (condition) {
>> b = createFoo(42);
>> } else if (otherCondition) {
>> b = new Foo();
>> } else {
>> // return b; // error, b is write only
>> return;
>> }
>>
>> // b is both read/write accessible at this point
>>
>>
>
> can't this be done with:
>
> Foo b = condition ? createFoo(42) :
>                      (otherCondition ? new Foo() : return);
> // use b

It solves the simplest examples, but not more complex ones, so it is not generic enough.