On Thu, May 5, 2022 at 10:33 AM Sébastien Bini via Std-Proposals <std-proposals@lists.isocpp.org> wrote:

[Avi Kivity wrote:] 

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

I cannot be called [...] as it could then lead to objects being destructed twice

Right, I think there's a mismatch between the way Avi was using/understanding the terminology and the way you (and I) use it.

- Immediately after a call to std::relocate_at (or the core-language `operator reloc` or whatever), the source object has become destroyed and its lifetime is over.

- But the destructor is not called.

This terminology is confusing in the context of today's C++, because today's C++ does not (admit|permit) any difference between the ideas of "the object's lifetime ends" and "the object's destructor is called." We are able to use the same English phrase — "the object is destroyed" — to mean both notions, interchangeably, without any ambiguity, because they are literally synonymous in C++ today.

In C++-with-relocation (whether P1144 or otherwise), it is possible for an object's lifetime to end in either of two different ways: either its destructor is called, or it is relocated-from. In the former case, its destructor is called; in the latter case, its destructor is never called. The phrase "the object is destroyed" should now be avoided, because it is ambiguous: it could be taken to mean either "the object's destructor is called," or "the object's lifetime ends," and these notions are now no longer synonymous.

The context was when a the object is not trivially relocatable and a relocate operator is not defined, and then the language falls back to std::move:

> 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.

I absolutely agree that if the object is trivially relocatable, or if a relocation operator is defined, the source object just ceases existing. But if relocation is not possible, the move fallback requires the destructor to be called (and my comment was that it's called immediately after the move constructor, the point where its scope ends).