Hi Edward, why do we need a temporary in those cases? Why not elide to just destroy? As is the case for other codepaths (e.g. after the else branch, for relocate in the if branch).   -----Ursprüngliche Nachricht----- Von:Edward Catmur <ecatmur_at_[hidden]> Gesendet:Do 19.05.2022 13:58 Betreff:Re: [std-proposals] Relocation in C++ An:Sebastian Wittmeier <wittmeier_at_[hidden]>; CC:std-proposals_at_[hidden]; On Wed, 18 May 2022 at 07:54, Sebastian Wittmeier <wittmeier_at_[hidden] <mailto:wittmeier_at_[hidden]> > wrote: *I would suggest that in those situations - 'reloc a' without using the result - the compiler may just call the destructor and end the scope instead of relocating to a new instance.* Yes, that sounds a very good idea, however there is something to consider: what happens if `a` cannot be destroyed immediately, if it is a function parameter without trivial or user relocation operation? Since you want to release resources, it will be necessary to move-construct a temporary instance of `T` from `a`, then destroy the temporary. On the other hand, if `T` has trivial or user relocation operation, then even if it is a function parameter the function is in full control of its lifetime so it can be destroyed immediately.  This could possibly be accomplished by an elision rule - eliding relocate + destroy to just relocate. However, that would make it optional and a matter of optimization with user-visible effects. It would probably be better to adjust the rules on *discarded-value expression* such that temporary materialization conversion is not applied if the discarded-value expression is a relocation expression. It would be important to ensure that this has the desired effect of move-constructing and destroying a temporary if necessary.