On Friday, August 7, 2020, 1:33:44 PM CDT, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote: On Fri, 7 Aug 2020 at 21:21, Walt Karas via Std-Proposals<std-proposals_at_[hidden]> wrote:
>
> On Friday, August 7, 2020, 12:57:08 PM CDT, Ville Voutilainen <ville.voutilainen_at_[hidden]> wrote:
> On Fri, 7 Aug 2020 at 20:47, Walt Karas via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> > You can't do a destroy+placement-new if the placement-new can throw.
> >
> > WK: OK, also good point. If the constructor can throw, then conceptually the default assign can be like this: https://godbolt.org/z/jvdf53
>
> That approach doesn't work for anything non-trivial, and requires
> C++20 implicit object creation otherwise.
>
> WK: Hmm can you give quick example of a class for which this would not work? Or can you give a smaller reference than two long (and expensive) books?


struct X
{
    std::string str;
};

This type can *NOT* be memcpyed, and restoring it from raw bytes is
equally non-doable.

WK: it's true that in general it can't be memcpyed. But, in this case we are guaranteed that only one of the copies will be destroyed, so it seems safe. In the generated assign, the raw data of the instance is copied off, and then copied back, to the original instance address before it is destoyed. I can't think of an example of a class for which this would not be safe.

struct Y
{
// data members omitted, they don't really matter
    Y(); // non-trivial
    Y(const Y&); // non-trivial
};

This type can *NOT* be memcpyed, and restoring it from raw bytes is
equally non-doable.