Instead of failing the construction could return the error in another way. Either as a stored error code. Or by using a factory method.   But to your suggestion:   std::construct_moved_from_at would need support by the class. Otherwise the class invariants could not be built.   So what is the distinction to a specific actual constructor, e.g. T{}?   a) The better clarity of code? (against a more complicated standard) b) that the compiler may optimize away a moved from construction directly followed by a destruction? c) the safety to flag any other usages of such a class except destruction?     -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 24.10.2025 17:24 Betreff:Re: [std-proposals] Replace an object -- but retain old object if new object fails to construct An:std-proposals_at_[hidden]; CC:Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>; On Friday, October 24, 2025, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden] <mailto:std-proposals_at_[hidden]> > wrote: I think that's an even more important question: how often do we need this replacement solution whereby the previously-stored object is present if the new one throws on construction?   Sometimes we at the very least want to be left with a safe-to-destroy object if the construction fails. Something like:      p->~T();     try     {         ::new(p) T(5, 6.22);      }     catch(...)     {         std::construct_moved_from_at<T>(p);     }  A few months back on this mailing list, somebody was talking about introducing "std::moved_from" and I think it's a good idea.   -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals