Ok, but how can a type that needs custom relocation still be
E.g. if you need a fixup for self-reference, then relocating won't
ever be as efficient as memcpy.
Yes, this is acceptable; performance is only one benefit of the proposal.
With operator reloc you will be able to skip a moved-from state check
inside destructor (and sometimes additional member), but that will
matter only if such types are stored in containers (i.e. there are a
lot of objects of this type).
It matters for the class author, who has to write all this extra logic and state for no benefit. Code that is not written does not have bugs.
Also in containers implementers can already do all kinds of
shenanigans to mitigate the cost (e.g. skip destructor call for
moved-from objects for types that they know it is safe to do).
And how do they know it is safe to do so? By nonstandardized attributes and special-case lists? Standardizing relocation allows everyone to communicate this property, between implementers, users, and third-party library vendors.
So the question comes down to this: is it really worth to introduce
even more complexity in the SMF area, for unknown benefit?
If you have a non-trivially relocatable type, then even the new SMF
operator reloc won't get you the same performance as similar trivially
Yes; this adds complexity in the special-member-function area, but it will allow removing complexity in user code.