Why doesn't C# realise that this reference type variable is guaranteed to be set?

[jez9999]

I have the following code:

private TestClass? getTestClass() {
    return new TestClass();
}

private void testMethod() {
    var testClass = getTestClass();
    var testBool = true;
    if (testBool) {
        testClass = new TestClass();
    }
    var someInt = testClass.IntMember;
}

The last line gives me a warning with nullable reference types: Dereference of a possibly null reference.

Why is this a possibly null reference? testBool must be true, the if block must get run, and the variable must be initialized to non-null. Oddly, if I change to if (true) it works. Why doesn't if (always-true-bool-variable)?

[HaloFour]

Because nullable flow analysis does not track boolean conditions across variable assignments. I believe that there is a proposal to expand that to support trivial cases like this one, but there will always be a limit to how far flow analysis will be willing to interpret and evaluate the code to determine which code paths may or may not execute.

[HaloFour]

I can't give concrete advice without concrete examples. I'd suggest that the majority of situations are covered by existing flow analysis, or can be through modest refactoring. If your example can't then that is a case where you can inform the compiler via the null-forgiveness operator or the like.

[CyrusNajmabadi]

which is not good.

Nullable analysis is best effort. And there is an unending amount of flow analysis that could be done to make more precise understanding of the code. No matter where you draw the line, some cases will fall through. That's literally why there is a suppression operator.

[tannergooding]

Notably there is also Debug.Assert(testClass is not null);, which I personally prefer over suppression

It does the same job, but is more readable/visible, provides a convenient place to breakpoint if it fails, and a convenient place to add any annotation/comment as to why it can’t be null for future readers (including yourself 3mo later)

[jez9999]

@tannergooding Unfortunately that doesn't work with the mechanism I'm using, which is to initialize the variable as a side-effect of a lambda passed to an awaited method that executes it. It won't let me do the Debug.Assert as it's sure that testClass is an uninitialized variable.

[jez9999]

@tannergooding It also doesn't work in this example if, instead of var testClass = getTestClass();, you simply write TestClass testClass;.