Handling of null values in computing switch expression exhaustiveness

[gafter]

The "nullable reference types" feature tracks when values in executable code likely can or cannot contain null. This would be useful in performing exhaustiveness analysis of a switch expression, because warning about a "possible" unhandled null in a switch expression is sort of pointless if the nullability analysis determines that the value ought not be null.

We'd like to organize the analysis so that exhaustiveness checking is sensitive to the results of the nullable analysis. To do that, the binding phase will assume (for the purposes of exhaustiveness analysis) that no value in a pattern-matching operation can be a reference null. If the nullable feature is enabled, the nullable checked pass will complete the analysis by checking for exhaustiveness in cases where some input value is null.

That means code like this

    int M(string s1, string s2)
    {
        return (s1, s2) switch {
            (string x, string y) => x.Length + y.Length
            };
    }

Will not get a warning that the switch expression is incomplete when the nullable feature is not enabled. When the nullability feature is enabled, the declarations of M's parameters are treated as non-null, and you won't get a warning on the switch expression because the two input values ought not to contain null. You would get a warning if a caller attempts to pass a null value to M though. If you change the code to take advantage of the "nullable reference types" feature

    int M(string? s1, string? s2) // NOTE: added nullability annotations on parameters
    {
        return (s1, s2) switch {
            (string x, string y) => x.Length + y.Length
            };
    }

Then a warning that the switch expression is incomplete will be produced by the nullable analysis pass.

(I don't know precisely when this was discussed in the LDM, but @jcouv, @AlekseyTs and I @gafter remember this being a decision)

[alrz]

Does this include the codegen where we check for null?

[gafter]

@alrz This would have no affect on the compile-time or runtime meaning of the code. It only affects warnings.

[gafter]

The binding work was done in #31093. All that remains is the work in the nullable analysis pass.

[alrz]

From design notes:

Current design: warning about not handling all inputs except null.

I think when this work is done one could use e! switch { .. } to exclude nulls.

[gafter]

@alrz That only affects whether the compiler thinks there could be null at the top level. It still tracks whether members of that top-level value contain null.

[alrz]

Yes, I'm proposing that it also affect subsumption checking when #nullable is enabled.

 int M(string? s1, string? s2) 
    {
        return (s1!, s2!) switch {  // ignore null on input
            (string x, string y) => x.Length + y.Length 
        }; // no warning on unhandled null because nulls are already ignored.
    }

I think this is better than "warning about not handling all inputs except null" because user opts in.

Furthermore, I think there should an easier way to suppress subsumption warnings because they could happen with other values as well, not just null.

[gafter]

Agreed; the compiler will (but doesn't yet) warn for incompleteness, but where it is incomplete because null isn't handled, only warn if the compiler infers that null is possible through the normal nullable analysis. It will still be possible, of course, to smuggle in a null and get a runtime exception for not handling it.

[alrz]

It will still be possible, of course, to smuggle in a null and get a runtime exception for not handling it.

This will be expected when you use ! anywhere, but it's visible and "forced" by user, also it only applies to that exact value, so a warning is still possible when null on some other input value is not handled.

[gafter]

@alrz It is also possible reading a not-yet-initialized field, a parameter that an evil caller passed null to, and many other ways.