Proposed resolution (November, 2018)

1. 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]

2. 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 mandatory not performed in a constant expression (11.9.6 [class.copy.elision]).

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

...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]

Notes from the March, 2018 meeting:

CWG concurred with the suggested direction.

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