Update “tuple” handling – rebased

[Nigel-Ecma]

Rebased version of PR #1538 after @jskeet moved some of the incidental changes (like proper subscripts) into the trunk in PR #1555

Addresses issue #1155
Replaces PR #1366, PR #1538

A “surgical” fix for issue 1155 was outlined and later tried in PR 1366 (spun off from an earlier PR), unfortunately it did not work (mea culpa). This PR is the less surgical fix…

As usual only files in /standard need be considered for review, other changes are largely machine-generated.

Overview of the PR (this list is not guaranteed to be complete):

• The syntax pattern ( <item>, <item>, … ) occurs in multiple places in C# with different meanings, e.g. parameter lists and tuples. The original presentation of “tuples” covered three different meanings using a single set of grammar rules and associated text. Unfortunately certain restrictions, such as where a declaration_expression is valid, where omitted in this compound description. By separating out the three meanings into tuple_literal, local_deconstructing_declaration, and deconstructing_assignment the PR addresses these issues using a combination of grammar and text.
• Unfortunately it was not always clear when the described manipulation of tuple constructions was occurring at compile or execution time. The PR addresses this, for an example see §12.7.
• Tuples are (currently?) unique among the language specified compound types in requiring a certain underlying implementation using a family of ValueTuple types (whose underlying implementation is left to the the implementation). The description of this requirement was distributed and incomplete; in particular while all tuples have a unique ValueTuple representation the reverse is not true and how to handle a ValueTuple value which is not equivalent to a tuple was unfortunately omitted. The PR concentrates the relationship into one clause and covers the missing cases.
• The conversions available for tuples was unfortunately incomplete, an issue raised by Tuple conversions are incorrectly specified #1155. This PR addresses this, and some reorganisation and clarification of the material was required to enable this.
• In destructions it was unfortunately not clear what the required order of evaluation of elements was, or whether they even needed to be evaluated.
• For discards it was not clear that they must have a type, e.g. it is invalid as part of a destruction to match a discard to a null as, though the value is unused, the discard has no type.
• The PR adds details on when implementations may elide intermediate tuples while maintaining the defined semantics of the language. For example (a, b) = (b, a); does not require tuple construction and deconstruction.
• Over time the number of uses & meanings of assignment in the language has increased and the text, and particularly the grammar, was unfortunately no longer as clear was one would wish. Tuples and destruction only added to this so as well as adding the new grammar and text required the PR does some reorganisation to clarify the grammar and make the text clearer.
• Overall the PR uses more precise grammar and reorganisaton of the text to improve the clarity of the Standard in this area.

In addition to these other issues were addressed as they came to light during development.

[jskeet]

Discussion result 2026-02-11:

• Jon will create a PR to:
  • Add the conversion from tuple type
  • Try to make as many of the ValueTuple concentration-in-one-place changes as possible
• We will see how many places refer to simple assignment, to gauge whether the split of simple assignment and deconstructing assignment will be messy outside the assignment operator section (and if it's not, we may try to get that in soon)
• We'll leave the tuple construction/deconstruction of tuple-ish types separation out for now (over the disagreement of Nigel)
• Nigel will make grammar checker changes separately, as they're required for patterns

[jskeet]

@BillWagner will create a branch for this (after Nigel's pushed a whitespace change) so that we don't lose the work.

[BillWagner]

Merging into feature branch tuple-research.

See new PR #1572 which contains the commits from this PR.