On Mon, 2 May 2022 at 12:30, Giuseppe D'Angelo via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Do you have examples of such classes?
>

>From my perspective, and this is predicated on relocation ending lifetime
such that the destructor is not called on relocated instances, an important
category of classes that can benefit from relocation is guard classes;
those that perform important work maintaining invariants in their
destructors. If instances of such classes are to be moved around - and
sometimes this is unavoidable, even with C++17 temporary materialization -
then they need to have a move constructor that tags the moved-from instance
such that its destructor does not perform the work. Sometimes this can be
done by setting a pointer member to nullptr, for example, but often a bool
data member is necessary. All this work could be avoided if move were
replaced with relocation, since the destructor would be called exactly once.

If I have something like
>
> template <typename T>
> void f(T &obj) {
> T temp = std::move(obj);
> }
>
> and I pass in e.g. a `const unique_ptr`, this code fails to compile.
> It's actually good that it fails to compile -- it's warning me that it'd
> be attempting a modification on a const object.
>
> Are you saying that if instead I use `reloc`, that code should compile?
> If so, does the benefit of "I can reloc const object" truly overcome the
> con of "the compiler lets me modify const objects"?
>

I believe this is covered in section 4.1 of the paper; `reloc` is only
valid on id-expressions denoting a complete object (not a reference)
previously initialized within the same function scope (and in scope, etc.).