The difficulty is not knowing, whether construction works. Otherwise the old object can be destructed first and the new one constructed.   To abstract this more, it is like a failing transaction, which can be rolled back.   A performant solution (same space) aside, do we need better primitives for transaction support? Even those involving multiple objects?   -----Ursprüngliche Nachricht----- Von:Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 24.10.2025 15:03 Betreff:Re: [std-proposals] Replace an object -- but retain old object if new object fails to construct Anlage:signature.asc An:std-proposals_at_[hidden]; CC:Thiago Macieira <thiago_at_[hidden]>; On Thursday, 23 October 2025 21:44:22 Pacific Daylight Time Simon Schröder via Std-Proposals wrote: > > For a good reason. It's one type that cannot survive the trick that > > Frederick suggested, because its constructors and destructors may access > > a global list of other mutexes. > > > > So please stop using it as an example for this particular need. Find other > > types. > > So, this means that currently we are only talking about movable and copyable > types? In that case the standard does not have to prescribe any tricks of > how to implement such functionality (but implementations could still use > it). I don't know. Can we find other non-movable, non-copyable types that could be emplaced in an optional or optional-like container? And where replacing it is also an expected use-case? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org  Principal Engineer - Intel Data Center Group -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals