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@lists.isocpp.org>
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@lists.isocpp.org;
CC: Frederick Virchanza Gotham <cauldwell.thomas@gmail.com>;


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@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals