CWG2941 [class.temporary] Lifetime extension for RefType{}

[hubert-reinterpretcast]

Full name of submitter (unless configured in github; will be published with the issue): Hubert Tong

Reference (section label): [class.temporary]

Link to reflector thread (if any): N/A

Issue description:
CWG 2894 will clarify that RefType{} produces a glvalue (instead of a prvalue). Once that happens, [class.temporary] will require an update to allow lifetime-extension of any temporary bound to the reference initialized by the function-style cast expression. In particular, the function-style cast is not mapped to static_cast, etc. in this case and the temporary materialization occurs within the initialization for the reference formed by the cast itself.

Implementations appear to agree already that such lifetime-extension occurs (https://godbolt.org/z/EWczhzaf6):

int glob;
struct A {
  constexpr ~A() { p = &glob; }
  int *p;
};
constexpr int f() {
  typedef const A &AR;
  const A &ref = AR{0};
  delete ref.p;
  return 0;
}
extern constexpr int x = f();  // okay

Suggested resolution:
Add a bullet to [class.temporary]/6:

• a

  • const_cast ([expr.const.cast]),
  • [ ... ]

  [ ... ]

• a function-style cast to a reference type where the reference is

  • bound directly to a glvalue operand that is one of these expressions
  • or bound to the result of a temporary materialization conversion

[jensmaurer]

CWG2941

[hubert-reinterpretcast]

@jensmaurer, thanks for creating CWG 2941.

Some comments:

• In the write-up, I think "a function-style casts" should be adjusted to "a function-style casts".
• In the suggested wording, I think relying on the cross-reference to disambiguate between the functional notation and the cast notation ([expr.cast]) for "explicit type conversion" is not ideal. "Function-style cast" is used in the majority of cases.
• In the suggested wording (my fault), I think we need to say:
  • a function-style cast (7.6.1.4 [expr.type.conv]) whose initializer is a braced-init-list that is to a reference type where the reference is
    • bound directly to a glvalue operand that is the glvalue result of one of these expressions that is the sole element of the braced-init-list
    • or bound to the result of a temporary materialization conversion,

[jensmaurer]

@hubert-reinterpretcast , thanks for your feedback.

• typo in write-up fixed (going singular all the way)
• I disagree with the "majority of cases". "function-style cast" appears a number of times for the discussion of parsing ambiguities, but a lot of other places talk about "explicit type conversion", sometimes with just the cross-reference, and sometimes with "(functional notation)" plus the cross-reference. I'm heading for the latter.
• I've updated the suggested resolution, switching the word order for the condition to something that I can read better.