2.2 KiB
C# Language Design Notes for Oct 10, 2018
QOTD: C# has a long and proud tradition of being oblivious
Agenda
- Pattern matching open questions
Discussion
- 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.