Nullable Reference Types: Not Null after await

[soraphis]

#nullable enable
public class Test
{
    public string? myString { get; set; } = null;

    public async Task MyTest()
    {
        myString = null;
        await Task.CompletedTask;
    }


    public async Task DoSomething()
    {
        if (myString == null) return;
        await MyTest();
        var s = myString.Substring(0); // <----------- it says: " 'myString' is not null here "
        Console.WriteLine(s);
    }

}
#nullable restore`

obviously after an await, every nullable member should be possibly null again.

[CyrusNajmabadi]

You don't need an await for this to happen either. After running any code, values may now be null again. However, this would lead to far too many false positives. So nrt uses heuristics to balance giving true positives while avoiding lots of false positives. This does mean that sometimes you won't get a warning.

[soraphis]

yeah, you're absolutely right about this, but I think for anything awaitable this is somewhat a special case, as "await" basically means: you intend that other stuff happens while you're waiting for the task to finish.

[CyrusNajmabadi]

This would again be a case of just too many false positives. Every await line would reset everything, and you'd have to check everything again to appease the checker. The rare case is something becoming null again. So this would flip the pain around on the common case.

[En3Tho]

In fact I don't really think that await is something special here. Any method call could change the internal state. The best thing you can do here is to use local variables nullability of whose won't change.

[soraphis]

I came to the kinda realization that it's maybe more of a problem for me, since I'm using Unity.
where objects - that still exist - are "== null" due to e.g. Destroy being called and the underlying c++ object being already deleted and things like that.
So even for local variables I have to check nullability again.

Any method call could change the internal state

but that's a different issue imho. You COULD inspect the the called method and see if it nulls/modifys a used member of yours. and you could do so recursively. While for await this isn't that easily possible. Since there is not necessarily a concrete thing to follow.