If the sole point for having std::relocate is for std::swap, why not have a magic compiler generated constexpr std::swap that uses relocation? I fear that having operator reloc and std::relocate will be confusing.
I've found use for std::relocate elsewhere, e.g. when implementing std::optional, std::variant. Also when decomposing std::tuple for std::apply, std::make_from_tuple.
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 don't see the need for push_back to take a tag parameter at all;
we can just add push_back by value: void push_back(T value);. Possibly
the overload resolution rules will need updating, or the existing
overloads (T&& / T const&) could be removed.
How would you update those rules?
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]
or, if not that,
> While the copy-and-swap (in this case, reloc-and-swap) idiom works
fine for this assignment operator, for gsl::not_null a memberwise
implementation would also work, indicating that this assignment operator
should be a defaultable special member function:
>
> not_null& operator=(not_null) = default;
That should work. Although I believe that assignment relocation could happen in terms of destruction + relocation, at least for types that support operator reloc().
The user can write destroy+relocate if they want; the language shouldn't be doing that.
> In turn, this indicates that the spelling for the relocation
operator should simply be T(T) - that is, it should have the syntax of a
constructor. Since a by-value constructor is currently invalid, this is
free syntax.
I am not thrilled by this :/
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).
- T(T) does not convey the intent like "operator reloc(T&&)" does;
- Users may find it confusing to have a constructor overload that takes parameters by value;
And an operator that behaves like a constructor / static constructor isn't confusing?
- T(T) would mean that the destructor of the parameter is called when the function exits, which is not the case;
The specialness of the constructor (relocating memberwise) is what prevents the destructor being called.
- That syntax would only imply that a copy of the object is performed and that copy is placed in the constructor parameter. While this is not what happens: `reloc obj` will simply pass 'obj' as parameter, and we lie when we say it's a pr-value. Unlike assignment-relocation (T& operator=(T)), where the parameter is an actual pr-value, returned by reloc. Unless I am missing something?
For assignment, it'd be better if also there is no new prvalue created, so that should be elided/avoided. It's not a lie to say it's a prvalue if that's the magic of reloc keyword-operator.
- This syntax would allow code like: T a; T b{a}; What happens then? Is the copy constructor called or the relocation constructor? If the latter, then `a` will be double-freed. If the former, then how does overload resolution figure this one out?
The copy constructor; a is an lvalue, so the constructor taking lvalue is preferred. If T doesn't have a copy constructor, this is ill-formed.