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.
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:
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,
@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.
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 tostatic_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):
Suggested resolution: Add a bullet to [class.temporary]/6:
a
[ ... ]