C# Language Design Meeting Notes, Oct 18, 2016

Agenda

Go over C# 7.0 features one last (?) time to make sure we feel good about them and address remaining language-level concerns.

1. Wildcard syntax
2. Design "room" between tuples and patterns
3. Local functions
4. Digit separators
5. Throw expressions
6. Tuple name mismatch warnings
7. Tuple types in new expressions

Pattern matching

Wildcards

If we want to reopen the discussion of using _, and it doesn't make C# 7.0, we may find ourselves wanting to block off use of _ as an ordinary identifier in the new declaration contexts (patterns, deconstruction, out vars). Let's front load the final design of wildcards to decide if anything needs to happen here.

Design "room" between tuples and pattern matching

case (int, int) x: is not currently allowed, in order to leave design space. More specifically we want this to mean a recursive pattern, rather than just a tuple type, once we get to recursive patterns. We're good with leaving this an error in the meantime, even though it may occasionally be puzzling to developers.

Local functions

We want to ideally allow any expression or set of statements to be lifted out in a local method. There are two ways in which this cannot be realized:

1. assignment to readonly fields in constructors - the runtime disallows those assignments if we lift them out to methods.
2. async methods and iterators - they aren't done executing when they return, so they can't generally contribute to definite assignment of enclosing variables. For async local functions we do recognize assignments that happen before the first await. Is this too subtle? Maybe, but it's fine to keep it.

Digit separators

We don't allow leading or trailing underbars - they have to be between digits: they are digit separators after all! We think this is fine, but if we hear feedback to the contrary we can try to relax it later.

Throw expressions

They are allowed as expression bodies, as the second operand of ??, and as the second and third operand of ?:. They are not allowed in && and ||, and cannot be parenthesized. We think this is a fine place to land.

Tuples

Name mismatch warnings

We don't currently warn about names moving to a different position. Should we?

(int first, int last) M() ...

(int last, int first) t = M(); // Oops!

Ideally yes. There are a lot of weird cases that would be hard to track down, though. Let's get the obvious ones. Essentially where we do implicit conversions we would check and warn.

Use of tuples in new

You cannot new up a tuple type. However, we should certainly allow arrays of tuples to be created. It is probably also fine to keep allowing newing of nullable tuple types:

var array = new (int x, int y)[10];   // Absolutely
var nullable = new (int x, int y)?(); // Why not?