Hi Tiago,   in the third given example there are two (movable) candidates with overlapping lifetimes. Would you still consider those for RVO?   Hi all, trying to find a good motivating example for better RVO: Example 1: Assume a non-movable final type without possible uninitialized/moved-from states / flags. The function access() is only allowed after setup succeeded successfully.   ```` Immovable im; // would already call the constructor access(&im); // not allowed due to not set up! setup(&im); access(&im); // not allowed due to error! ```` If something goes wrong, setup cannot immediately destroy im, would have to rely on caller to immediately leave scope. Even an exception from setup() is no good guarantee. One could argue the same could happen later on, but it is more likely to happen during setup.   Example 2: Let us stay with the burned example. mutex. But not the locked one. Everytime a std::mutex is created, we want to enforce a log message (at least for debug builds). The enforcement should be technical by the framework and not by documentation or by code review.   Possible solutions:  - use the preprocessor (really?)  - derive LoggedMutex from std::mutex (would change the type; only possible for non-final classes)  - keep std::mutex as attribute within custom class (would change the type)  - use UB (no-go)  - call a factory method (needs RVO)   (I would recommend changing the type to also get a message at destruction.)     Best, Sebastian   -----Ursprüngliche Nachricht----- Von:Tiago Freire via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Do 23.05.2024 14:06 Betreff:Re: [std-proposals] std::elide An:std-proposals_at_[hidden]; CC:Tiago Freire <tmiguelf_at_[hidden]>; Example 3: [...] { Movable A; Movable B; //... if(condition() { return A; //Move, both A and B are considered for RVO } else { return B; //Move, both A and B are considered for RVO }