csharplang/meetings/2018/LDM-2018-10-10.md

C# Language Design Notes for Oct 10, 2018

QOTD: C# has a long and proud tradition of being oblivious

Agenda

1. Pattern matching open questions

Discussion

All questions are in this issue

Short discard diagnostics

Conclusion

We've taken breaking changes like this before, but there's more risk to this one because this code is legal all the way back to C# 1.0. This will not be an error -- an underscore in a case block with a constant _ in scope will match the constant. A warning wave warning should be added to make matching a constant named _ a warning.

Nullable reference types vs switch analysis

In general, the nullable analysis computes very similar information to switch exhaustiveness. It would be strange if the switch produced information contrary to the nullable analysis. There are some fundamental language semantic problems with making switch (and pattern) exhaustiveness and nullable analysis depend on each other. One possibility may be to perform the analysis for both of these situations simultaneously. We don't think that the exhaustiveness analysis doesn't affect the nullable analysis directly. Alternatively, we can phrase exhaustiveness as exclusive of nullable reference types and let the null analysis handle switch exhaustiveness for null specifically. Nullable value types would be handled as part of traditional exhaustiveness.

Conclusion

Let's explore the separation of exhaustiveness between null and non-null, st. all exhaustiveness warnings do not consider null, and warnings related to null are delayed until nullable analysis.

Also, regardless of whether or not we generate a warning for the following case, i is not definitely assigned at the end:

int i;
switch (s)
{
    case string t: i = 0; break;
}
Console.WriteLine(i); // is i definitely assigned?

Permit optionally omitting the pattern on the last branch of switch expr

Conclusion

Rejected.

Should exhaustiveness affect definite assignment?

Conclusion

Confirmed the current behavior.

Switch expression as statement expression

Conclusion

We like it. Not sure it will make it for C# 8.0.

Single-element positional deconstruction

Conclusion

We need to think about 1-tuples again.