Another point: std::relocate_at(p, q) is just new (p) T(std::relocate(q)). So if anything it's std::relocate_at that's unnecessary.

I agree with you on the confusion; since we expect non-experts to use operator reloc only, std::relocate could be given a longer, more technically oriented name.

I agree with both statements.

As a tiebreaker, prefer passing by value for prvalue arguments. Specifically, I would amend [over.ics.rank]/3.2.3 to read:

- neither of S1 and S2 bind a reference to an implicit object parameter of a non-static member function declared without a ref-qualifier, and either:
- S1 binds an lvalue reference to an lvalue, and S2 does not, or:
- S1 binds an rvalue reference to an xvalue, and S2 does not, or:
- S1 does not bind a reference, and S2 binds a reference to a prvalue, or:
- S1 binds an rvalue reference to a prvalue, and S2 binds an lvalue reference [Example:
int i;
int f1();
int&& f2();
...
int g2(const int&);
int g2(int);
int g2(int&&);
int j2 = g2(i); // calls g2(const int&)
int k2 = g2(f1()); // calls g2(int)
int l2 = g2(f2()); // calls g2(int&&)
...
- end example]

That sounds nice and shouldn't break existing APIs as they would today be considered as ambiguous.

The user can write destroy+relocate if they want; the language shouldn't be doing that.

As a user I would feel uncomfortable explicitly calling the destructor on *this to reconstruct it again.

This does require a bit of a conceptual leap, yes. The key is to understand that operator reloc *changes the value category* of a named object, from lvalue to prvalue. This is because relocation is the inverse operation to prvalue materialization. So by the time the relocating constructor is invoked, the argument is already a prvalue (just, uh, a prvalue that occupies storage).

Just to be sure I understand correctly: the reloc operator would no longer return a newly built instance (i.e. a temporary), but instead would merely transform the value category from lvalue to prvalue?

And then whether a temporary is materialized or not depends on the context, right?

Consider a type T with that putative relocation constructor T(T):

Case 1:

void foo(T a_foo);

T var;

foo(reloc var);

In `foo(reloc var);` is a_foo constructed using T(T)?

If so then `var`'s destruction is delegated to T(T), which prevents the destructor call of its parameter, right?

Case 2:

Now let's add a T& operator=(T):

T objA, objB;

objA = reloc objB;

Following the same logic as above, objB is passed to relocation constructor, and then to objA's assignment operator, right?

Case 3:

T obj;

reloc obj; // premature end-of-scope

This turns obj into a prvalue that is captured nowhere. I guess in this case the destructor of obj is simply called?

Case 4:

void bar(T&& bar_param);

T var;

bar(reloc var);

Again, reloc var turns var into a prvalue, but bar cannot capture it. So a temporary object of type T is created and its address is passed to bar, right?

If I understand correctly, then this could simplify some aspects of how operator reloc works.

However I fear many users will be lost (most C++ programmers that I know have no knowledge of value categories), and will find it quite disturbing to have a relocation constructor with that signature T(T). Sure operator reloc(T&&) may be confusing as well, but my personal take is that it would be less so :/