The ship has already sailed on adding the "no_unique_address" feature
to C++, but back when it was being designed, I would have made two
suggestions:
    1) The unary & operator and the 'addressof' function cannot take
the address of a 'no_unique_address' object.
    2) If you want the address of a 'no_unique_address' object, you must do:

        std::memcpy( std::addressof_no_unique(b.a), &a, sizeof b.a );

This would make it a lot more obvious where 'memcpy' gets involved.
Although of course someone could just do:

    A *pa = std::addressof_no_unique(b.a);
    std::memcpy( pa, &a, sizeof *pa );

so it's not totally bullet-proof. But anyway, going back to my
original code for 'abandoning' the std::future<bool> object:

    memset( &obj.value(), 0, sizeof obj.value() ); // not needed
but paranoia is good
    ::new( &obj.value() ) std::future<bool>();

I'd be better off getting rid of the invocation of 'memset'. Or. . . .
alternatively . . . . if there were to be two new functions in the
standard:

    template<typename T>
    consteval size_t trailing_padding_size(void) noexcept
    {
        return compiler_magic;
    }

    template<typename T>
    consteval size_t sizeof_minus_trailing_padding(void) noexcept
    {
        return sizeof(T) - trailing_padding_size<T>();
    }

then we could change the 'memset' to the following:

    memset( &obj.value(), 0,
sizeof_minus_trailing_padding<decltype(obj.value())>() );



On Wed, Nov 29, 2023 at 3:36 PM Sebastian Wittmeier via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> How does the compiler know, whether it can internally do a memcpy-like optimization for trivially copyable objects? Or it (nearly) never does?
>
> Which would be a huge missed optimization opportunity for objects, which are meant for being copied in a simple way (=trivially copiable objects) - without having to read, modify and write back the last few bytes, or - if possible on the platform - without writing single bytes below the word size.
>
>
> -----Ursprüngliche Nachricht-----
> Von: Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]>
> Gesendet: Mi 29.11.2023 16:11
> Betreff: Re: [std-proposals] void std::optional<T>::abandon(void) noexcept
> An: std-proposals_at_[hidden];
> CC: Frederick Virchanza Gotham <cauldwell.thomas_at_[hidden]>;
> On Wed, Nov 29, 2023 Lénárd Szolnoki via Std-Proposals wrote:
> >
> > The precondition for memcpy is trivially copyable *and* not potentially
> > overlapping. The former doesn't imply the latter.
> >
> > https://godbolt.org/z/xhsqdoz3s
>
>
> I've been playing around with this on GodBolt:
>
> https://godbolt.org/z/Ecd338Go8
>
> The output of this program on Linux x86_64 GNU g++ 13.2.0 is:
>
> Address of b.a.i == 140727507144480
> Address of b.a.ch == 140727507144484
> Address of b.maybe_extra_byte == 140727507144485
> 77
> 0
>
> So I am able to screw up the value of 'maybe_extra_byte' by memcpy'ing
> over the A object that exists inside B. Is this what the committee
> intended?
>
> If this _is_ what the compiler intended, then should every C++
> compiler issue a diagnostic whenever you pass the address of a
> 'no_unique_address' object to memcpy?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals