> ...and many more. :) You should read Appendix C:

Its all literally self-reference scenario, for example google protobuff checks some global table pointers which point to it again (its literally self reference again)

In any of this scenarios optimizations not possible, only which container will do if knows that type is trivially destructible after move. I see that 'swap' as move behavior is superior and highly used in all std library and my own types

вт, 20 июн. 2023 г. в 18:55, Arthur O'Dwyer <arthur.j.odwyer@gmail.com>:

On Tue, Jun 20, 2023 at 6:05 AM Nikl Kelbon via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
I've been working on improving trivial relocation proposals and I think I've found a new tool in a language we don't use

About relocation:

There are few possibilities to create move ctor:
1. trivial memcpy
2. exchange with default state
3. self reference scenario
4. do not have move ctor at all

...and many more. :) You should read Appendix C:
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1144r8.html#non-trivial-samples

[...] then we can add trait
is_not_self_reference<T>
(traits checks if T has field or base class with non 'swap'/'default' move recursivelly)

We need a solution that can reliably distinguish MSVC's std::list from libc++/libstdc++'s std::list.
(The former uses the "sentinel node" technique; the latter two use the "dummy node" technique. You need to learn the difference between them.)

What if we add trait is_trivially_destructible_after_move?

You're describing Niall Douglas's P1029. Watch "Trivially Relocatable" (2019), particularly slide 109.

–Arthur