On Mon, May 30, 2022 at 1:56 PM Edward Catmur <ecatmur@googlemail.com> wrote:
On Mon, 30 May 2022 at 11:25, Arthur O'Dwyer <arthur.j.odwyer@gmail.com> wrote:

I strongly discourage making any Memmi/Derrida–style subtle distinctions between the words "immobile" and "immovable."

I suggest phrases like "types that have an `operator reloc` but no move constructor" (describing the physical situation) or "types that are conceptually movable but lack any moved-from state" (describing the conceptual situation).

Well, yes, but that's a bit of a mouthful, so people will come up with a more concise terminology, or at best an initialism.

Maybe, but you don't have to help them. ;)

[...]
template<class T> requires std::is_noexcept_relocatable_v<T>
void swap(T& lhs, T& rhs) {
    T temp = relocate_at(&lhs);
    new (&lhs) T(relocate_at(&rhs));
    new (&rhs) T(relocate_at(&temp));
}

(relocate_at is the magic library function that (destroys and) relocates its argument into a returned prvalue.)

Terminology nit: `relocate_at` takes a pointer parameter `dest`, just like `construct_at` and `destroy_at`.
`relocate` with no suffix is the magic library function that relocates into a returned prvalue.
https://quuxplusone.github.io/blog/2022/05/18/std-relocate/


The advantage of a syntax is that you can express trivial relocation simply by defaulting it, and it Does The Right Thing if any member becomes non-trivial.

Pedantic terminology nit: Just like with any other special member, `=default` on your `operator reloc` wouldn't mean it was trivial; it would just mean it was defaulted, i.e., memberwise.
struct A { std::string s; operator reloc(A&&) = default; };  // memberwise and trivial
struct B { std::any a; operator reloc(B&&) = default; };  // memberwise and non-trivial

Absolutely, yes; and that's an advantage, since it means that a memberwise (defaulted) relocation operation is trivial precisely when each subobject is trivially relocatable; you won't end up making mistakes when changing data members or if another programmer changes the semantics of a type that you use.

Aside: is std::string necessarily trivially relocatable? I seem to remember in the old days some SSO strings that used self-reference, but maybe no library implementor has gone for that strategy.

I already linked to that blog post. :)
https://quuxplusone.github.io/blog/2019/02/20/p1144-what-types-are-relocatable/
TLDR: std::string is trivially relocatable on MSVC and libc++ (in non-debug mode); but not on libstdc++ because pointer-to-self.

–Arthur