> On Nov 12, 2025, at 8:34 AM, Thiago Macieira via Std-Proposals <std-proposals_at_[hidden]> wrote:
>
> On Tuesday, 11 November 2025 23:45:28 Pacific Standard Time Oliver Hunt via
> Std-Proposals wrote:
>> I’m not sure what you mean here? You could relocate from one location to a
>> potentially overlapping destination, and the semantics as specified
>> maintained the dynamic type. E.g the functional behaviour - absent
>> technologies like pointer authentication - was identical to memmove, this
>> included the hazard of performing a relocation where the static type did
>> not match the dynamic type, which could result in object slicing, and a
>> host of problems the follow from that.
>
> That might be dangerous by itself. Today, containers must allocate+move+free,
> which means the destination's dynamic type is always chosen by the container
> itself, causing object slicing. There's no such thing as moving with a
> retained dynamic type. Suddenly, if the container becomes capable of
> relocation, it might relocate without slicing.
>
> However, I do not recognise this as a valid use-case. Different container
> implementations will grow at different thresholds, and memory allocators will
> cause reallocations at different thresholds. Any code that attempts to retain a
> different dynamic type is *already* broken, in spite of however many safety
> hacks the developer may have used (e.g., reserve()).

Yeah, I’ve spent some time yesterday and today talking to the TR folk, while they were describing the semantics as maintaining equivalence to memmove based implementations (which do retain the dynamic type) their intent/assumption was copy constructor-like reversion to the static type of the objects being relocated. It’s an irksome miscommunication as I did explicitly bring up the problem of mismatching dynamic and static types as a hazard on many occasions, but so it goes. Of course there is also the problem of people expecting to be able to move “ABI compatible” objects, which may be disliked and UB but is certainly something I have seen previously. I’m just not sure how much of a problem it will be in practice - my bigger concern is that no matter how it is specified people will simply write `if (is_trivially_relocatable_v<T>) memmove(….)` which will be annoying but perhaps locally diagnosable.

Anyway, that change in apparent semantics does simplify the implementation and obviously resolves the need for an origin address as it of course is now simply being overwritten with a constant (trustable) address. My preference given such semantics would be to mandate overwriting the dynamic type everywhere to insure agreement between implementations, giving TR of polymorphic objects the semantics of a fast copy/move constructor. Or of course mitigate the entire problem by disallowing TR of polymorphic objects in the first place, due to this class of hazard.

—Oliver