Improved Definite Assignment Analysis

[RikkiGibson]

Improved Definite Assignment Analysis

Summary

Definite assignment analysis as specified has a few gaps which have caused users inconvenience. In particular, scenarios involving comparison to boolean constants, conditional-access, and null coalescing.

Related discussions and issues

Probably a dozen or so user reports can be found via this or similar queries (i.e. search for "definite assignment" instead of "CS0165", or search in csharplang).
https://github.com/dotnet/roslyn/issues?q=is%3Aclosed+is%3Aissue+label%3A%22Resolution-By+Design%22+cs0165

I have included related issues in the scenarios below to give a sense of the relative impact of each scenario.

Scenarios

As a point of reference, let's start with a well-known "happy case" that does work in definite assignment and in nullable.

#nullable enable

C c = new C();
if (c != null && c.M(out object obj0))
{
    obj0.ToString(); // ok
}

public class C
{
    public bool M(out object obj)
    {
        obj = new object();
        return true;
    }
}

Comparison to bool constant

• Proposal: Definite assignment involving == and != when compared to a constant boolean value #801
• [Question] Why the output is CS0165 when using a is Constant pattern. roslyn#45582
  • Links to 4 other issues where people were affected by this.

if ((c != null && c.M(out object obj1)) == true)
{
    obj1.ToString(); // undesired error
}

if ((c != null && c.M(out object obj2)) is true)
{
    obj2.ToString(); // undesired error
}

Comparison between a conditional access and a constant value

• Null-safe navigation and null-coalescing break the out variable initialization detection roslyn#33559
• Use of null propagation and out variables #4214
• Conditional operators and definite assignment #3659
• Compiler Prediction Error #3485
• Conditional operators and definite assignment #3659

This scenario is probably the biggest one. We do support this in nullable but not in definite assignment.

if (c?.M(out object obj3) == true)
{
    obj3.ToString(); // undesired error
}

Conditional access coalesced to a bool constant

• Extend definite assignment to understand null and nullable values and ?. #916
• Improve definite assignment to understand coalescing with false and nullable comparison with true #3365

This scenario is very similar to the previous one. This is also supported in nullable but not in definite assignment.

if (c?.M(out object obj4) ?? false)
{
    obj4.ToString(); // undesired error
}

Conditional expressions where one arm is a bool constant

• "Use of unassigned local variable" CS0165 issue roslyn#4272

It's worth pointing out that we already have special behavior for when the condition expression is constant (i.e. true ? a : b). We just unconditionally visit the arm indicated by the constant condition and ignore the other arm.

Also note that we haven't handled this scenario in nullable.

if (c != null ? c.M(out object obj4) : false)
{
    obj4.ToString(); // undesired error
}

Specification

The specification has moved to https://github.com/dotnet/csharplang/blob/main/proposals/csharp-10.0/improved-definite-assignment.md

[RikkiGibson]

@jcouv, @cston, and I recently met to discuss whether to move forward with this essential approach or to try to do a more "thorough" approach involving introducing the concepts of "state when not null" and "state when null" which would propagate out of conditional accesses and be "converted" to "state when true" and "state when false" when comparisons are performed.

We concluded that it is probably a prohibitive amount of work to go that way. For C# 10 we should go with the more piecemeal approach outlined in this specification. This way, we will address most of the scenarios that have been giving people pain, without spending an unreasonable amount of resources on the feature.

Please feel free to follow up if you wish to amend this summary in any way 😉

[RikkiGibson]

Also: the feature will probably be able to handle patterns in switch statements and switch expressions the same way it handles them in is, which is that:

• simple constant patterns such as a?.b(out x) switch { true => UseX(x) } should work, but
• patterns or equality comparisons over tuple literals, such as (a?.b(out x), 0) switch { (true, ) => UseX(x) } will probably be prohibitively difficult to get working.