
# C# Language Design Notes for Dec. 16, 2019

## Agenda

1. Switch expression as a statement expression
2. Triage

## Discussion

### Switch expression as a statement expression

https://github.com/dotnet/csharplang/issues/2860 

The proposal being discussed is whether to allow the switch expression without a discard:

```C#
_ = a switch
{ 
    ...
};
// becomes
a switch 
{ 
    ...
};
```

One of the against is that it makes for a confusing decision in the language as to whether you
use a switch expression or switch statement. Right now the guidance is simple: if you are in a
statement context, use a statement. If you have an expression context, use a switch expression.
Now, for a statement, you could use either a switch statement, or a switch expression in
statement form. It's not clear which.

One way of resolving this is that these are two parallel features that provide similar features
in a slightly different syntax and semantics. Then the answer simply becomes, use whichever one
you like better. If the new switch expression form includes exhaustiveness checking, that would
be a reason to use or not to use it, aside from the syntax differences. Similarly, the switch
statement ability to `goto` another case is a reason to use that form. However, if we accept
that, the switch expression feels artificially limited. To provide a satisfactory parallel
feature we have to augment the switch expression to allow for statements in the switch arms. Then
there is a potential new set of features: block in switch expressions.

On the other hand, this feels like feature creep. The original proposal was quite simple: allow
users to elide `_ =` and remove the requirements for the arms to have a common type. While we may
want to have a number of different new features for switch expression to make it comparable to
the switch statement, there's value in doing the feature as-is, and adding those features later.
This is contingent on us being fairly confident that the new features can be added without
breaking changes, but there's a fair amount of confidence that we know where we would go with the
feature. This perspective would require us to keep certain behaviors to ensure that the switch
expression keeps its differences from the switch statement. For instance, the new switch
expression-as-statement would have to check exhaustiveness if we see it as a strict improvement
for the switch expression.

Lastly, we all find the proposed switch expression-as-statement requiring a semicolon i.e.,

```C#
a switch
{
    b => ...,
    c => ...
}; // semicolon required
```

as being extremely ugly.

**Conclusion**

Rejected as-is. We'd be interested in a new proposal on this topic, addressing many of the
concerns that we brought up today.

### Triage

#### Definite assignment of private reference fields

**Conclusion**

Accepted for warning waves v1, wherever that is triaged.

#### Remove restriction on yielding a value in the body of a try block

Also for async iterators.

Issue #2949

**Conclusion**

Accepted, Any Time.

#### Generic user-defined operators

Issue #813

**Conclusion**

There's no syntax in the invocation to specify the type arguments, in case inference doesn't
succeed, and we think almost any syntax in the invocation location would be ugly. In addition, we
don't have a lot of examples of why this would be significantly better than alternatives (like
writing a method).

Rejected.

#### Support for method argument names in `nameof`

Issue #373

It looks like there's a significant breaking change if we allow the parameter names to be in
scope generally.

```C#
const int p = 3;
[Attribute(Property = p)]
void M(int p) { }
```

If we just allow `nameof` to have special scoping to allow the names in the method declaration to
be in scope, then there's no language breaking change. The scoping rules would prefer names in
the method header (including type parameters) over rules in the rest of the program.

**Conclusion**

Accepted, Any Time.