3.9 KiB
C# Language Design Notes for Dec. 16, 2019
Agenda
- Switch expression as a statement expression
- 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.