On Friday, 2 July 2021 08:15:03 PDT connor horman via Std-Proposals wrote:
> If the
> constructor is invoked with a temporary argument in the position of the
> temporary, then the lifetime of that temporary is extended to match the
> lifetime of the object under construction
Does that include when new'ing such a type?
new Type(reference_to_be_lifetime_extended);
Does it get extended for the lifetime of the dynamic type? And how does the
destructor know to end it?
No, for that exact reason. I could make it considerably more painful and do that (maybe it could store the temporary in that memory, and tell the delete expression to destroy it), but that's a rabbit hole I'd rather not wander down right now. This is why I mentioned it has to be automatic, static, or thread storage duration (though that's in the specification section, and the text you cited was in the high level description, so I probably should have made the same clear there).
Basically, the rule applies whenever lifetime extension would have applied if the temporary initialized an rvalue reference instead. Though, does `new std::initializer_list<int>{1,2,3,4};` lifetime-extend the temporary array (I'd assume not, but if so, that may be a potential argument).
PS: the usual discussion about whether this should be an attribute or a full
keyword is missing. Remember: a compliant implementation of an attribute is to
do nothing.
I did mention in Drawbacks that this would require an implementation to provide the specified behaviour of the attribute. Although, I guess I did omit the argument that it should be a keyword (assuming it would be implicit). I'm unsure whether making it a full keyword would be a good idea, but if making an attribute with a required effect is a non-starter, I guess it would be the only other solution (I doubt it could work as a contextual keyword).
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel DPG Cloud Engineering