On Monday, 2 May 2022 12:01:38 PDT Jason McKesson via Std-Proposals wrote:
> To me, the entire point of putting "relocation" into the language at
> all is to remove destructor calls for things that we can't remove
> destructor calls for in any other way. If "relocation" only applies to
> dynamic lifetime objects, then "relocation" is a matter of convention,
> not of the language. That is, you just don't call the destructor for
> it if you relocated it; [basic.life]/5 already effectively declares
> that this is fine so long as your program doesn't rely on any
> side-effects from the destructor being called.

It's slightly more than that, as it is standardising a way of doing something
we're currently abusing the standard for, and declaring that this
functionality is available.

Currently, we memcpy() non-trivial objects like QString in QList. The language
says we shouldn't do that, that using the newly-created QString without
calling its constructor isn't allowed and that not calling the freed QString's
destructor before it's freed is probably a resource leak. In my opinion,
that's what we need to fix, so containers are more efficient.

For local variables, I don't see much of a difference between relocating and
moving.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering