Re-add 12-16 notes

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

@@ -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.