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


On Friday, October 24, 2025, Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org> 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@lists.isocpp.org
 https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals