[expr.sub] Clarify "identical (by definition) to"

[Eisenwave]

Reference (section label): [expr.sub]

Issue description

[expr.sub] paragraph 2 states that:

The expression E1[E2] is identical (by definition) to *((E1)+(E2))

It is unclear whether the unconventional term "identical (by definition)" (which appears only once in the document) means

• identical only in result (which influences whether array-to-pointer conversion takes place, which mattered in CWG2548), or
• expression-equivalent.

Proposed resolution

Update [expr.sub] paragraph 2 as follows:

 The expression E1[E2] is
-identical (by definition)
+expression-equivalent
 to *((E1)+(E2))

[frederick-vs-ja]

How about transforming E1[E2] to "more actually" equivalent forms?

The expression E1[E2] is ~identical (by definition)~ expression-equivalent to *((E1)+(E2)) ~, except that in the case of an array operand, the result is an lvalue if that operand is an lvalue and an xvalue otherwise~ *if none of E1 and E2 is an array rvalue, or `static_cast<T&&>(((E1)+(E2)))` otherwise**.

Also, I'm afraid that they are not so that identical or expression-equivalent, although "expression-equivalent" is perhaps fine because the difference are out side of the evaluation of these expressions. Perhaps it would be better cherry-pick the following part from the abandoned resolution of CWG2548.

[Note ?: The semantics of E1[E2] differ from those of *((E1)+(E2)) or static_cast<T&&>(*((E1)+(E2))) ~also~ for

• lifetime extension of temporaries (6.7.7 [class.temporary]) and

• changing the active member of a union via assignment (11.5.1 [class.union.general]).

  — end note]

[jensmaurer]

"expression-equivalent" is a library concept; I'd like to avoid using it in core. What's wrong with just saying "is equivalent to"?