Improve nullability inferencing by unrolling simple properties

[sjb-sjb]

Recognizing that full inferencing of nullability can be a challenge but consider this:

    private Blog[]? Blogs { get; }

    public bool IsEmpty => this.Blogs == null;

    public string Name( int i) 
    {
        if (this.IsEmpty) { throw new IndexOutOfRangeException(); }
        string name = this.Blogs[i].Name;
    }

Desired: no nullability warning
Actual: nullability warning on this.Blogs[i], saying that this.Blogs may be null.

[333fred]

This is what MemberNotNullWhen was added to C# 9 for.

[sjb-sjb]

Makes sense but isn't this something the compiler should be able to figure out?

[333fred]

For simple scenarios, possibly. But what defines when a scenario is simple or not? I don't believe there is any good way for "this is simple" vs "this is not simple" to be communicated to a user. It is much better to allow these things to be specified explicitly. For example, IsEmpty might exist in another assembly, and the compiler cannot load that dll, examine the bytecode for that property, and use it to inform the current compilation.

[yaakov-h]

For what its worth, even Code Contracts best attempts to infer state rules fell apart on any non-trivial codebase and required the developer to annotate their code anyway.