Oliver is a gentleman, Frederick is also a nice guy, and most people here are nice....sometimes the email text is hard to express your vision so it is natural that some friction happens so now and then.This has been said, let's all be patient and modest toward each others.As for the subject in discussion, i suggest to read Giuseppe D'Angelo article about relocation, he gives a rigorous discussion.https://www.kdab.com/qt-and-trivial-relocation-part-1/I would like to attract your attention to his IntRef class.Sent from my Galaxy
-------- Original message --------From: Oliver Hunt via Std-Proposals <std-proposals_at_[hidden]> Date: 10/30/25 3:56 AM (GMT+01:00) To: std-proposals_at_[hidden] Cc: Oliver Hunt <oliver_at_[hidden]> Subject: Re: [std-proposals] Replace an object -- but retain old object if new object fails to construct On Oct 29, 2025, at 5:41 AM, Frederick Virchanza Gotham via Std-Proposals <std-proposals_at_[hidden]> wrote:I’m not going to reply to your earlier email. This is a professional mailing list, and that reply was offensive. I recognize that you are posting on this list through an anonymous pseudonym so perceive no consequences for yourself, but no one else on this list is.Based on that response it is clear that you have no respect me, or my anything I have said despite expending a huge amount of time and effort replying to your proposals.This entire thread consists of you making incorrect statements, coming to incorrect conclusions, and repeatedly saying some variation of “I need to test it”, rather than just Reading. The. Specification.I really dislike any kind of appeal to authority, but in this case your offensive dismissal of my earlier reply means I have no qualms about it. I am done with patience. I have extended a great deal of patience, and I believe acted with professionalism in all our prior communication. The same cannot be said for your actions on this list, especially in this thread, where you prior to dismissing my reply, you referred to Thiago as “T Dogg”, a name that I ever seen an email by which he requested he be addressed.As such we’ll go the authority route. I am the expert on pointer authentication in WG21. I am the expert on how it interacts with trivial relocation. I do not make this claim lightly. I do not believe you would find any member of this standards body who disagrees with this assertion.I have replied below. I think you should read it, though your prior response doesn’t give me much reason to expect it.On Wednesday, October 29, 2025, Giuseppe D'Angelo wrote:

Test what? What is there to prove or disprove?
To show programs crashing (or not crashing) on arm64e when a polymorphic object is trivially relocated and then has one of its virtual methods invoked.arm64e has thrown such a spanner in the works for the standardisation of C++ that we need it on GodBolt for testing to see what crashes and what doesn't crash.Also unrelated to relocation, I need an arm64e compiler and executor to do work on this:https://www.virjacode.com/papers/polyhandle.htmNo. You don’t.I don’t know why you think you need to “test” it. In prior emails you have insisted on writing code relative to specific implementations as if that somehow relates to the standard. Implementation details are just that, and are not relevant in determined what the standard permits. Please stop trying to do this.You have misunderstood multiple aspects of trivial relocation.Trivial relocation is intentionally not `memcpy` or `memmove`, it is performed via std::trivially_relocate. If an implementation of C++ has std::is_trivially_relocatable<T> return true for some type T, then std::trivially_relocate<T> must work. If an implementation cannot relocate an object of type T, then std::trivially_relocate<T> must return false. Clang does this.Whatever the final specification for trivial_relocation of polymorphic type is, clang will provide a conforming implementation.I know this, because I worked with the authors of P2786 to ensure that it was possible, given the proposal's decision to permit trivial relocation of polymorphic objects.I know this, because I implemented it.P2786 discusses polymorphic classes because it must: trivially relocating an object is not meant to change the dynamic type of an object vs the default copy constructor which will change the dynamic type if they do not match, so that must be specified. There is no intrinsic reason that this was required, it could just as easily have said that polymorphic objects are never relocatable. Given existing NB comments that may well become the case.P2786 includes specific wording to support arm64e’s ABI, wording that I helped with, to support the case of polymorphic types being trivially relocatable, while a union of trivially relocatable types that include a trivially relocatable polymorphic type is not.You do not need to “test” anything. What would you be testing?A compiler is conforming or it is not conforming. You can rest assured that all C++ compiler authors are doing their best to make sure that they are conforming. You do not need to “test” a feature by executing code, unless you believe that there is an implementation bug.Also unrelated to relocation, I need an arm64e compiler and executor to do work on this:https://www.virjacode.com/papers/polyhandle.htmPlease use your real name in proposals.We went through your dynamic_cast from void months ago, and explained why it does not work. Your proposal does not add the specification of a vtable, so it cannot make use of even the concept of one - as we said last time C++ has no such notion, so you would have to add it. Your proposal is _still_ focused on the fact that you wrote an implementation, not a specification.Your proposal still does not work. It cannot correctly produce null when dynamic casting from a non-polymorphic type, despite a void* being perfectly capable of being such. This was all explained months ago. There are myriad other problems with it. They have not changed. Read the old the threads."For the topic at hand clang currently does not support trivial relocation of polymorphic types - and reports correctly that such are not."Basically he's saying that the following assertion will always succeed: static_assert( false == (is_polymorphic_v<T> && is_trivially_relocatable_v<T>) );Re-read the statement you quoted. Trivial relocation of address discriminated types is implemented, the only reason I have landed it is that the current specification of trivial relocation does not seem 100% guaranteed, as there are a number of NB comments opposed to trivial relocation of polymorphic types, so it seemed that the safer option was to not permit it. For any type T the semantics of is_trivially_relocatable<T> and trivially_relocate<T> are correct.If you read P2786, you will find that it literally quotes me.I saw a reply from Arthur that I have not yet read (sorry!), but while we have disagreed about the exact semantics of trivial relocation, I think we both agree that the core semantic requirement is simply that if is_trivially_relocatable<T> is true, then trivially_relocate<T> must work. Everything else is just choices about what types are relocatable.Now the fact that clang does not permit trivial relocation of these types today is entirely irrelevant - if the specification makes a feature required for conformance then it gets implemented. There a numerous features in multiple compilers that are not complete. This is not new or novel. Again, you do not need to “test” this. This list is for discussing the standard, not implementations of the standard. They may come up, but only in the context of an actual proposal.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.Again no. If it did that, the implementation would not be conforming.Trivial relocation means you can just move the object byte-by-bytewithout any further processing. There is no mutation of the bytes --they are moved verbatim without being edited.What are you talking about? That is explicitly not what it is. You cannot copy a trivially relocatable object byte by byte. Per the specification, the only permissible method to relocate a trivially relocatable object is std::trivially_relocate. If you do anything else your code is wrong, and is invoking undefined behavior.The re-signing isn't a no-op -- it has an observable side effectAgain irrelevant, trivial relocation makes no claims of bitwise equality. An implementation of trivially_relocate may not be a byte for byte even absent pointer authentication: if a compiler determines that it is faster to not copy padding, it is free not to. You are inventing semantics that do not exist in the specification.I really hope nobody suggests that 'memcpy' or 'memmove' shall havespecial behaviour when the object being relocated is polymorphic . . .. I really hope nobody goes there.No one is suggesting any such thing. You do not understand the specification, and are writing incorrect code as a consequence: template<typename T> requires std::is_trivially_relocatable_v<T> void Relocate(T const *const p, T *const q) { char unsigned const *from = (char unsigned const *)p;       char unsigned       *to   = (char unsigned *)q; for ( std::size_t i = 0u; i < sizeof(T); ++i ) *to++ = *from++; }This code is wrong, end of story. Both for correctness reasons - if clang reports a polymorphic object as trivially copyable, and you decide to copy it byte by byte, you can end up with an invalid object at the end, because your code is wrong by construction.Your code is also incorrect without pointer authentication, because absent trivial relocation, you cannot transfer object lifetime, and so this code is UB in many (all?) cases.But are we all in agreement that re-signing (or re-encrypting) apointer is __not__ trivial ? And therefore, that all polymorphicobject are __not__ trivially relocatable on arm64e?No, I am not, and I would guess neither is anyone else [1] because what you have described and drawn conclusions from is not the specification.What it means to be “trivial” is something that Arthur and I disagree on, but per the specification, my implementation, and (here’s where Arthur and I really disagree) the hardware it is. As of today at least: C++26 is not finalized, and there are NB comments on trivial relocation, so it may change.If, during finalization of C++26, the specification changes to say trivially relocation is performed as if it were a byte by byte copy, the specification would also change to make the trivial relocatability of polymorphic types be implementation defined behavior. No matter where it ends up, an implementation is non conforming if there is any type where is_trivially_relocatable returns false, and trivially_relocate fails.Read the specification of trivial relocation, rather than guessing about the semantics and making incorrect statements and jumping to incorrect conclusions.Finally: This is a professional list, participants are expected to conduct themselves as such. I’ve already had to tell you not to attack me personally, now I’m having to tell you to act professionally on this list.—Oliver[1] Arthur: this is a comment on just what the semantics are per the specification today, I’m not suggesting you agree with them :D
-- Std-Proposals mailing listStd-Proposals_at_[hidden]://lists.isocpp.org/mailman/listinfo.cgi/std-proposals