This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 115f. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2024-12-06
[Accepted as a DR at the February, 2019 meeting.]
The resolution of issue 2022 does not work, as it is mathematically impossible to guarantee the named return value optimization in all cases. For example:
struct B { B *self = this; }; extern const B b; constexpr B f() { B b; if (&b == &::b) return B(); else return b; } constexpr B b = f(); // is b.self == &b?
Here an implementation is required to perform the optimization if and only if it does not perform the optimization.
The resolution would appear to be to reverse the resolution of issue 2022 and guarantee that named return value optimization is not performed in constant expression evaluation.
Notes from the March, 2018 meeting:
CWG concurred with the suggested direction.
Proposed resolution (November, 2018)
Change 7.7 [expr.const] paragraph 1 as follows:
Expressions that satisfy these requirements, assuming that copy elision (11.9.6 [class.copy.elision]) is not performed, are called constant expressions. [Note: Constant expressions can be evaluated during translation. —end note]
Change 9.2.6 [dcl.constexpr] paragraph 7 as follows:
A call to a constexpr function produces the same result as a call to an equivalent non-constexpr function in all respects except that
a call to a constexpr function can appear in a constant expression (7.7 [expr.const]) and
copy elision is
mandatorynot performed in a constant expression (11.9.6 [class.copy.elision]).
Change 11.9.6 [class.copy.elision] paragraph 1 as follows:
...Copy elision isrequirednot permitted where an expression is evaluated in a context requiring a constant expression (7.7 [expr.const]) and in constant initialization (6.9.3.2 [basic.start.static]). [Note: Copy elision mightnotbe performed if the same expression is evaluated in another context. —end note]