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


2278. Copy elision in constant expressions reconsidered

Section: 7.7  [expr.const]     Status: CD5     Submitter: Richard Smith     Date: 2016-06-27

[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)

  1. Change 7.7 [expr.const] paragraph 1 as follows:

  2. 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]
  3. Change 9.2.6 [dcl.constexpr] paragraph 7 as follows:

  4. A call to a constexpr function produces the same result as a call to an equivalent non-constexpr function in all respects except that

  5. Change 11.9.6 [class.copy.elision] paragraph 1 as follows:

  6. ...Copy elision is required not 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 might not be performed if the same expression is evaluated in another context. —end note]