When introducing exceptions and destroy order, this feature gets really complicated with all the special cases from P2025R2.   Let us simplify to get rid of lots of the special cases:  - A function cannot combine guaranteed NRVO and guaranteed URVO.  - A function with guaranteed NRVO always constructs the return value at the start of the function.     // uses guaranteed URVO mutex Func() {     if (cond)         return unlocked_mutex();     else         return locked_mutex(); }   // uses guaranteed NRVO auto locked_mutex() -> mutex m{} {     m.lock();     return m; }   // uses guaranteed NRVO   auto unlocked_mutex() -> mutex m{} {     return m; } Now exception handling and destruction order should be simple.       -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mo 20.05.2024 00:00 Betreff:Re: [std-proposals] std::elide An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Sun, May 19, 2024 at 10:49 PM Sebastian Wittmeier wrote: > > auto Func() -> mutex m > { >     if (cond) >         return Func2(); >     else >     { >         std::construct(m); >         m.lock(); >         return m; >      } > } Or maybe like this: mutex Func(void) {     try     {          if ( cond ) return Func2();          else          {              auto &m = std::construct( /* ctor arguments go here */ );              m.lock();              return m;           }    }    catch(...)    {          if ( std::is_constructed_already() ) return std::constructed_object();          std::construct( /* ctor arguments go here */ );          std::constructed().lock();          return std::constructed();    } } -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals