Ok, but how can a type that needs custom relocation still be
efficiently relocatable?
E.g. if you need a fixup for self-reference, then relocating won't
ever be as efficient as memcpy.

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).
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).

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
relocatable type.

Regards,
Maciej

pon., 30 maj 2022 o 18:23 Arthur O'Dwyer via Std-Proposals
<std-proposals_at_[hidden]> napisał(a):
>
> On Mon, May 30, 2022 at 11:37 AM Edward Catmur via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>
>> On Mon, 30 May 2022 at 09:26, Maciej Cencora via Std-Proposals <std-proposals_at_[hidden]> wrote:
>>>
>>> Can't we base relocation on move+destroy only? (or just memcpy + end
>>> of scope in case of trivially relocatable types).
>>>
>>> I.e.:
>>> Obj a;
>>> auto b = reloc a;
>>>
>>> At 'reloc a' line, we either:
>>> 1) construct 'b' by invoking move constructor from 'a', invoke
>>> destructor for 'a', remove 'a' from scope
>>> 2) construct 'b' by memcpy-ing 'a', do not invoke 'a' destructor,
>>> remove ab' from scope
>>
>>
>> We expect there to exist types that are immovable and [non-trivially] relocatable.
>
>
> FWIW, I (in P1144) consider that an oxymoron. A type that is immobile/immovable cannot be relocatable, because it's not movable. Immobility is for types that cannot be moved from place to place — like `std::mutex`, for example. Typically they cannot be moved because if you moved them then bad things would happen.
> Similarly, if you "relocated" a `std::mutex`, bad things would happen. You can't have a mutex suddenly change memory addresses and expect the rest of the program to just be cool with that.
>
> The right answer to Maciej's question is: Because you expect there to exist types that are efficiently relocatable but not trivially relocatable.
> One real-world example is
> struct S {
> std::any a; // non-trivially relocatable
> std::list<int> b; // MSVC: trivially relocatable, inefficiently movable
> };
> To move-construct an `S`, you need to move the any (using its move-ctor) and then move the list (using its move-ctor, which allocates memory because MSVC uses a sentinel-node implementation).
> But to relocate an `S`, you merely need to move-and-destroy the any (still using its move-ctor, presumably) and then relocate the list (using its relocation operation, which is tantamount to memcpy, and does not allocate).
> Move-constructing an `S` allocates, and is non-noexcept.
> Relocating an `S` doesn't need to allocate, and can be noexcept.
> However, `S` is not trivially relocatable.
>
> So, it's tempting to look for some syntax to express a relocation operation that is different from move+destroy and yet also different from memcpy.
> That's what Sébastien is doing here (and also Pablo in N4158, and Denis in P0023).
>
> Relevant:
> https://quuxplusone.github.io/blog/2019/02/20/p1144-what-types-are-relocatable/
>
> –Arthur
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals