Refactor pattern description?

[Nigel-Ecma]

This is unresolved in #873 and suggests a refactor, some of it seems to echo the current role of §12.7 for tuples – an extension of §12.7 to include ITuple just for patterns could be considered as part of any refactor of patterns.

Patterns themselves are expanding in v9 so any refactor should be considered in that light; so I’ll mark this one as a v9 issue.

---

I’ve sprinkled a “few” ;-) comments and suggestions across the files, this is a wrap up to those.

Overall I think the presentation order of the material is quite confusing and/or overly complex, which has led to errors creeping in; leading to the view that a refactor is needed.

A couple of examples: grammar & semantic grouping; handling tuple-like things.

---

Grammar & semantic grouping

Consider local_variable_declaration, it is split into explicitly_typed_local_variable_declaration and implicitly_typed_local_variable_declaration (we ignore ref_local_variable_declaration as patterns have no corollary). The description covers the similarities and differences between the two.

Now consider declaration_pattern and part of var_pattern:

declaration_pattern
    : type simple_designation
    ;
    
var_pattern
    : 'var' simple_designation // ignoring *tuple_designtation for now - see below
    ;

The first of these defines explicitly typed value matches, the second implicitly typed, both of which introduce a variable (including the discard one _) – the correlation with local variable declaration is clear. Rather than describe these two together they are split into separate non-adjacent clauses. This may have led to the errors in describing how a user-defined var type is handled, an issue with local variables as well (though a different resolution is used for patterns).

A triple of declaration_pattern, explicitly_typed_declaration_pattern and implicitly_typed_declaration_pattern describing the similarities, differences, and how a user-type var is handled might be more understandable/clear – aided by it following the same approach as for local variable declarations (the ones not in patterns, these patterns also declare local variables!)

But what of the part of var_pattern this does not cover?

var_pattern
    : 'var' tuple_designation
    ;

This is a shorthand for a positional_pattern, described before positional patterns themselves are introduced. Would not describing the long form first be better? So this part of var_pattern could move to after positional_pattern.

So the current var_pattern is a melding of two only slightly related things, a refactor could separate then and associate each part to what they are more closely related to.

Coming to positional_pattern we see it is a rule with 4 non-terminals, all optional, and two terminals, open & close parentheses. Such a structure suggests its doing a lot of things, but that might be due to our next example.

---

Handling tuple-like things

The syntax* of declaration, var, constant and positional patterns suggest that these C# patterns match:

1. Single constants
2. Single values, which could be of simple or complex types
3. Tuples of any combination of 1-3 (so including tuples of tuples)

However the semantics has (3) matching:

• Tuples
• Types with a Deconstruct method which provides a representation of the type as an ordered sequence of values – like a tuple does.
• Types which implement ITuple – through which they present themselves as tuples

It might help the description if this was refactored out under some heading, I used tuple-like as a placeholder above but leave the choice open, which could simply the description of positional patterns (and others?)

The positional pattern grammar might benefit from losing some of the optionals and list the valid combinations as alternatives.

---

TL;DR

I recommend a refactor & grammar re-org.

Originally posted by @Nigel-Ecma in #873 (review)