One would likely do it as opt-in instead of as opt-out.   That was the discussion of changing the standard and object model/lifetime to allow cryostasis.   If you start this discussion, you can also think about marking serializable/deserializable or even beyond processes or program executions. Those are from an object perspective related properties. A similar one is cloning. -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Fr 24.10.2025 13:50 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, Sebastian Wittmeier wrote: You don't know the reason the object is unmovable. The address space of the object may be mapped to the hardware. Copying and restoring may lead to errors.   Simple example: A DMA buffer.   You could get this on a microcontroller too, where addresses above 0x2000 are volatile memory, and addresses from 0x0 to 0x800 are the input for a digital-to-analog converter.  And so if the 'replace' template function were to be added to the C++ Standard library, then some classes would need to be given a tag to indicate that you can't put them into temporary cryostasis, something like:  namespace std {     class mutex {     public:         typedef int no_cryostasis;     }; }    -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals