(non)nullable types

[Nick Sabalausky]

"Nick Sabalausky" <a at a.a> wrote in message 
news:gn4g2n$fbf$1 at digitalmars.com...
> "Denis Koroskin" <2korden at gmail.com> wrote in message 
> news:op.upazx0d4o7cclz at proton.creatstudio.intranet...
>> On Fri, 13 Feb 2009 21:43:22 +0300, Nick Sabalausky <a at a.a> wrote:
>>>
>>> I still like this that someone else mentioned:
>>>
>>> T? x = something;
>>> if(x !is null)
>>> {
>>>     // x is implicitly "T" here, not "T?"
>>> }
>>> else
>>> {
>>>     // handle null condition (x is still "T?")
>>> }
>>>
>>>
>>
>> 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.
>

Another thing to think about is delegates. Even if classes are non-null by 
default, we can still get the same old null reference problem with 
delegates:

class Foo
{
    void delegate() dg;
    void callDg()
    {
        dg();  // Oops! Forgot to check for null!!
    }
}

void main()
{
    auto f = new Foo();
    f.callDg();
}

This could probably be solved by whatever mechanism is used for classes.