# 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?