68 lines
2.9 KiB
Markdown
68 lines
2.9 KiB
Markdown
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?
|
|
|
|
``` c#
|
|
(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 `new`ing of nullable tuple types:
|
|
|
|
``` c#
|
|
var array = new (int x, int y)[10]; // Absolutely
|
|
var nullable = new (int x, int y)?(); // Why not?
|
|
```
|