Null-safe dereference prevents out var from being definitely assigned even when result is non-null

[jnm2]

I would expect a to be definitely assigned since == true implies != null which means TryA was definitely executed (sharplab):

using System;

public class B
{
    public bool TryA(out int a)
    {
        a = 42;
        return true;
    }
}

public class C
{
    public B B { get; }
    
    public void M()
    {
        if (B?.TryA(out var a) == true)
        {
            Console.WriteLine(a);
        }
    }
}

Is there a good reason for this or is it just not implemented yet?

[yaakov-h]

I assume this is applicable? dotnet/roslyn#12514 (comment)

[jnm2]

@gafter

Although you might like the compiler to do better here, the behavior is as specified for the ?. operator and the ?? operator. The ?? operator does not specify any special behavior for definitely-assigned-when-true and definitely-assigned-when-false when its result happens to be of type bool.

This is not specific to bool though. Reference types are the same way. So long as the comparison you do implies != null, the type should be irrelevant. (example)

[gafter]

@jnm2 Right, there is also no special behavior specified for definitely assigned when non-null.

[jnm2]

@gafter Cool. Is there any reason we couldn't have it?

[gafter]

@jnm2 Right now “it” is mythical. It would be very complex to specify, implement, and test, for little value to programmers.

[NickCraver]

I think we may want to revisit this with nullable changes proposed for C# 8, still hitting this fairly often.