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](https://github.com/dotnet/csharplang/issues/1054)

### 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:

```C#
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.