Open issue: list-pattern questions for 1/3/2022

[jcouv]

Previous discussion: https://github.com/dotnet/csharplang/blob/main/meetings/2021/LDM-2021-10-20.md#slices-that-return-null

If a Slice method is annotated, we will treat it as potentially returning null for the purposes of subsumption and exhaustiveness.

Example of scenario with annotations (not so bad, since only affects a warning):

#nullable enable

public class C 
{
    public int Length => 0;
    public int this[int i] => 0;
    public C? Slice(int i, int j) => null;
    public void M() 
    {
        _ = this switch
        {
          null => 0,
          [..not null] => 1,
          // warning CS8655: The switch expression does not handle some null inputs (it is not exhaustive). For example, the pattern '[.. null]' is not covered.
        };
    }
}

But the weirdness is not limited to nullable-annotated Slice methods. It happens whenever Slice returns a reference type:

System.Span<int> s = default;
switch (s) 
{
    case [..[1],2,3]:
    case [1,2,3]: // error (The switch case is unreachable. It has already been handled by a previous case or it is impossible to match.)
        break;
}
 
int[] a = default;
switch (a) 
{
    case [..[1],2,3]:
    case [1,2,3]: // no error
        break;
}

@alrz proposed to not have a null-test during the slice operation. Yes, this could result in unexpected behavior (null-ref exception, which patterns typically avoid), but that's the case for all other assumptions we've been baking into list-patterns.

After email thread, we have 3 options:

1. status quo (emit null-test and keep above difference in diagnostics)
2. remove the null-test (and thus error in both scenarios above)
3. perform reachability analysis without null-test (same diagnostics as option 2) but include null-test in codegen (same runtime behavior as option 1)
4. perform reachability analysis and codegen with a "Slice and throw if null" operation

FYI @AlekseyTs @333fred @CyrusNajmabadi

Relates to list-patterns (proposal)

[alrz]

I'd add a fourth option "removing assumptions on the slice value entirely" because this is a very unlikely scenario in real code and a solution that could also keep the nullability analysis intact while emitting the null check (not mentioned in the OP) doesn't seem to worth it to go through. That would result in no error for both cases.

[jcouv]

LDM 1/3/2022: landed on option 2 (remove the null-check)