Repository navigation
CWG3063 [class.temporary] Lifetime extension of temporaries to opaque lifetimes past function return #760
Description
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:
P2748R5, "Disallow Binding a Returned Glvalue to a Temporary" only adds an error for functions that return references but entirely strikes the provision that prevents lifetime-extension of temporaries bound to the return value of a function. It thus creates situations whereby temporaries created within a function can be lifetime-extended to lifetimes that are opaque to the function.
Consider:
struct B { ~B(); };
struct A { const B &b; };
A foo() { return {{}}; }
void bar();
int main() {
A a = foo();
bar();
}Based on guaranteed copy elision, the reference that the B temporary is bound to is the a.b from main. [class.temporary] says that the lifetime of the B temporary is extended. This requirement is not practical to implement.
Suggested resolution:
Restore [class.temporary] bullet 6.11 from C++23.
- The lifetime of a temporary bound to the returned value in a function
returnstatement ([stmt.return]) is not extended; the temporary is destroyed at the end of the full-expression in thereturnstatement.
Activity
jensmaurer commentedon Sep 12, 2025
CWG3063
Note the added emphasis on reference members.
[-][class.temporary] Lifetime extension of temporaries to opaque lifetimes past function return[/-][+]CWG3063 [class.temporary] Lifetime extension of temporaries to opaque lifetimes past function return[/+]hubert-reinterpretcast commentedon Sep 12, 2025
Got it. Thanks Jens!
t3nsor commentedon Sep 12, 2025
I think, if I had remembered this lifetime extension case during drafting, I would have advocated that it also be banned in a return statement based on the same rationale: it immediately dangles. That is to say, [stmt.return]/6 could say something like
with an additional example as well.
If we go with the current proposed resolution, maybe it should also be updated to use "constituent reference". The problem is that it should apply not only to reference members but also reference members of subobjects.
hubert-reinterpretcast commentedon Sep 12, 2025
We may want to move "constituent reference" out of [expr.const] though.
jensmaurer commentedon Sep 14, 2025
I've updated CWG3063 accordingly.