On Mon, May 30, 2022 at 11:37 AM Edward Catmur via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
On Mon, 30 May 2022 at 09:26, Maciej Cencora via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Can't we base relocation on move+destroy only? (or just memcpy + end
of scope in case of trivially relocatable types).

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