Add LDM notes for Dec. 16, 2019
This commit is contained in:
parent
59e6c6bfdf
commit
ee1bf2bd8e
2 changed files with 129 additions and 5 deletions
122
meetings/2019/LDM-2019-12-16.md
Normal file
122
meetings/2019/LDM-2019-12-16.md
Normal file
|
@ -0,0 +1,122 @@
|
|||
|
||||
# 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.
|
|
@ -17,11 +17,6 @@
|
|||
- re-discuss `x is object` being a pure null test
|
||||
- consider `var?` to avoid "un-var'ing" for nullability (e.g. https://github.com/microsoft/vs-threading/pull/538/file)
|
||||
|
||||
## Dec 16, 2019
|
||||
|
||||
- https://github.com/dotnet/csharplang/issues/2860 Switch Expression as a Statement Expression (continued) (Neal, Fred)
|
||||
- https://github.com/dotnet/csharplang/projects/4#column-4649189 Triage recently championed features
|
||||
|
||||
## Dec 9, 2019
|
||||
|
||||
- https://github.com/dotnet/csharplang/issues/2850 Proposed changes for pattern-matching (continued) (Neal)
|
||||
|
@ -38,6 +33,13 @@
|
|||
|
||||
Overview of meetings and agendas for 2019
|
||||
|
||||
## Dec 16, 2019
|
||||
|
||||
[C# Language Design Notes for Dec 16, 2019](LDM-2019-12-16.md)
|
||||
|
||||
1. Switch Expression as a Statement Expression (continued) (Neal, Fred)
|
||||
2. Triage
|
||||
|
||||
## Dec 11, 2019
|
||||
|
||||
[C# Language Design Notes for Dec 11, 2019](LDM-2019-12-11.md)
|
||||
|
|
Loading…
Reference in a new issue