On 05/05/2022 23.48, Arthur O'Dwyer wrote:
> On Thu, May 5, 2022 at 10:33 AM Sébastien Bini via Std-Proposals
> <std-proposals_at_[hidden]> 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).