csharplang/meetings/2019/LDM-2019-12-16.md

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:

_ = 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.,

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.

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.