That's the question. What does trivial relocatibility actually mean:   A) That the sub-objects are all trivially relocatable and that the order does not matter and no custom standard member functions have to be called B) That the bytes can be copied/moved   A) is more from a language user (C++) and abstract machine perspective B) is more from an implementation perspective     IMVHO I would tend to A as the better definition, but having in mind that not following B would make it more difficult to get an optimization advantage on the respective platforms.   But then the question is, how does trivial relocatibility interact with memcpy and other ways to access the raw byte representation of the object.   -----Ursprüngliche Nachricht----- Von:Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> Gesendet:Mi 29.10.2025 15:00 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 Wed, Oct 29, 2025 at 1:39 PM Giuseppe D'Angelo wrote: > > > On an arm64e computer, if you relocate a polymorphic object, and then > > invoke a virtual method, the attempt to access the vtable will cause a > > CPU trap because the vtable pointer will be incorrectly encrypted. > > This is not the case; the vtable pointer gets correctly re-signed during > trivial relocation. Trivial relocation means you can just move the object byte-by-byte without any further processing. There is no mutation of the bytes -- they are moved verbatim without being edited. The re-signing isn't a no-op -- it has an observable side effect, and if you remove that observable side effect then the program will crash (i.e. the CPU will trap when it tries to dereference an incorrectly-encrypted pointer). -- Std-Proposals mailing list Std-Proposals_at_[hidden] https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals