Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

C# Design Notes for Oct 18, 2016 #16482

Closed
MadsTorgersen opened this issue Jan 12, 2017 · 1 comment
Closed

C# Design Notes for Oct 18, 2016 #16482

MadsTorgersen opened this issue Jan 12, 2017 · 1 comment

Comments

@MadsTorgersen
Copy link
Contributor

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?
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants