On Mon, 2 May 2022 at 11:24, Sébastien Bini via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Stating that the moved-from object is invalid and should not be touched again is (in my opinion) a bad class design. You may have a look at https://herbsutter.com/2020/02/17/move-simply/, which further motivated me to write this paper. Quoting Herb Sutter: "In C++, an object is valid (meets its invariants) for its entire lifetime, which is from the end of its construction to the start of its destruction (see [basic.life]/4). Moving from an object does not end its lifetime, only destruction does, so moving from an object does not make it invalid or not obey its invariants." Relocation allows to make an object invalid before it is destructed, albeit it is never touched again except by its destructor.

A destructor may call arbitrary methods on the class under destruction, which will have no way to tell that the instance they are invoked on was previously relocated. How will you ensure safety in this scenario? It seems that there will be a considerable burden on the class author to ensure that all methods called from the destructor are safe to be called on a relocated instance, since the language will not ensure this, and a considerable maintenance burden going forward.

Far better to terminate the lifetime immediately and omit calling the destructor entirely.
The reloc operator introduces a language-level guarantee (no use after relocation) that will always be better than an external tool that developers may simply not run.

If this is language-level, the language can immediately terminate the lifetime. In the if/else case, lifetime can be terminated with a destructor call at the end of the branch where relocation does not occur.

I am still open to discuss the syntax. I would be in favor of a solution that doesn't introduce a new constructor and a new type of reference, but I still haven't found it :/

Firstly, don't introduce a new value category; we already have more than enough. If the instance lifetime is terminated immediately, there is no need for another value category since there will no longer be an object in its storage.

My suggestion for syntax would be *prvalue qualification* on class member functions, with relocation implemented as prvalue qualified conversion to the same (class) type:

struct A {
    operator A() prvalue;  // or "reloc", or "~", or "&(false)", etc. - note that the qualification position is relatively free syntax