Another unresolved issue from #873. Since this comment was made §12.7 Deconstruction has been revised and does not refer to compiler-generated variables. §12.7 is used to keep tuple clauses from needing to reference Deconstruct in multiple places, and might be suitable as a basis for simplifying §11 in the same way.
This is a low-level implementation description, there should be no talk of “compiler-generated variables” – that is an implementation detail.
We need to re-think how Deconstruct is woven into the description of pattern matching – as an approximation pattern matching may be performed on single (simple or compound) values, tuples of values (or types which implement ITuple?), and on compound values that offer to present themselves as “tuple-like“ (pick a suitable term) by providing Deconstruct.
If we can get this covered upfront the descriptions of the different patterns forms should be a lot simpler/clearer.
Originally posted by @Nigel-Ecma in #873 (comment)
Another unresolved issue from #873. Since this comment was made §12.7 Deconstruction has been revised and does not refer to compiler-generated variables. §12.7 is used to keep tuple clauses from needing to reference
Deconstructin multiple places, and might be suitable as a basis for simplifying §11 in the same way.This is a low-level implementation description, there should be no talk of “compiler-generated variables” – that is an implementation detail.
We need to re-think how
Deconstructis woven into the description of pattern matching – as an approximation pattern matching may be performed on single (simple or compound) values, tuples of values (or types which implementITuple?), and on compound values that offer to present themselves as “tuple-like“ (pick a suitable term) by providingDeconstruct.If we can get this covered upfront the descriptions of the different patterns forms should be a lot simpler/clearer.
Originally posted by @Nigel-Ecma in #873 (comment)