This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 114a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-04-18
According to 7.6.2.4 [expr.await] bullets 3.3 and 3.4,
Evaluation of an await-expression involves the following auxiliary types, expressions, and objects:
...
o is determined by enumerating the applicable operator co_await functions for an argument a (12.2.2.3 [over.match.oper]), and choosing the best one through overload resolution (12.2 [over.match]). If overload resolution is ambiguous, the program is ill-formed. If no viable functions are found, o is a. Otherwise, o is a call to the selected function with the argument a. If o would be a prvalue, the temporary materialization conversion (7.3.5 [conv.rval]) is applied.
e is an lvalue referring to the result of evaluating the (possibly-converted) o.
...
However, the temporary materialization conversion produces an xvalue, not an lvalue. Should e be a glvalue instead of an lvalue?
Rationale (February, 2021):
The specification is as intended; o is converted to an lvalue if it is an xvalue result of the temporary materialization conversion. e is used in both bullets 3.7 and 3.8; if it were an xvalue instead of an lvalue, the call to await_suspend could steal e's resources and leave the call to await_resume with a defunct object, which would be undesirable.