On 03/05/2022 12.42, Sébastien Bini via Std-Proposals wrote:
> Hello all,
>
> I've been digesting yesterday discussions, and here is what I can
> propose to move forward:
>
> * types cannot be relocated if they don't have a copy constructor or
> a move constructor defined and accessible.
> * we remove relocation references and the relocation constructor.
> * we introduce a new "operator reloc(T&& rhs)" static member
> function in classes, which will act both as a constructor and a
> destructor (much like P0023 relocator). This function can be
> defaulted, implicitly declared and defined just like constructors.
> This would likely require new syntax bits, more on that later.
> * we keep the reloc operator. Calling reloc on an object will
> "relocate" the instance and mark the end of scope of its name. How
> the object is "relocated" is left to compiler vendors. The
> language offers the following relocation methods:
> o If the type is trivially relocatable (p1144), then using
> std::memcpy is authorized. If this method is used then the
> language enforces that the destructor of the relocated object
> is not called.
> o If the type provides an accessible "operator reloc" method,
> then it can be used to perform the relocation. Again the
> language enforces that the destructor of the relocated object
> is not called.
> o Simply use a regular move (std::move). The destructor of the
> moved instance is called normally (i.e. when it goes out of
> scope).
>

That is, the destructor is called immediately, since the reloc operator
ended the scope of the name. I think that's a good thing.