69 lines
2.6 KiB
Markdown
69 lines
2.6 KiB
Markdown
# 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,)`).
|
|
|
|
``` c#
|
|
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.
|
|
|
|
## Colon or is?
|
|
|
|
|