2.6 KiB
C# Language Design Notes for Nov 20, 2017
Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!
Agenda
Recursive pattern matching
Grammar
The grammar splits out to a couple of cases so that the right things are optional etc. directly in the grammar.
That separation is also there in the representation of the implementation, currently. An alternative is to have a single production and call it out in prose. There are advantages to having a separated representation, in that your code can make more assumptions about what's there or not.
Names in deconstruction pattern
What is the utility? Current proposal it's only to guarantee that you get the thing you say. It does not allow reordering or leaving out elements.
This pattern should by and large work like deconstruction. But it's plausible to have names here, even if we don't in deconstruction; the argument would be a symmetry with constructors, which are sometimes used with names and optional arguments.
Should the identifier be restricted from being a discard?
Since it can be left out completely? No, it's probably good to allow the discard. For refactoring etc.
Matching via ITuple
It's "too likely" that the compiler would consider that a thing may
implement ITuple.
We'll restrict to static types object, ITuple and any type that derives from ITuple and has no deconstructors.
dynamic is treated just like object. We don't go looking for deconstructors dynamically.
Syntactic ambiguity around parenthesized expression
Should we even have single-element deconstruction patterns?
Could require some other element to disambiguate, e.g. (2) _.
This would raise the cost of adding single-element tuples and deconstruction in the future, at least if they have a syntax other than parenthesized expressions (e.g., (x,)).
switch(my1DPoint)
case 1DPoint(0):
...
case 1DPoint(var x):
...
Compromise position: Allow a single one only if there is a type in front. It gives the obvious symmetry with a single-element constructor, without restricting the design space for future single-element tuples or pattern grouping constructs.
Cast ambiguity
Now went away. It's a cast, or an error.
Short discard
Yes, allow _ as a pattern in and of itself. It would not be allowed at the top level in an is expression. (That is allowed today, and designates the type _).
It actually means something different than default in a switch, because it gets an error if there are no cases left. That seems useful.
So: allow it everywhere except at the top level in an is-expression.