> ...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_at_[hidden]>:

> On Tue, Jun 20, 2023 at 6:05 AM Nikl Kelbon via Std-Proposals <
> std-proposals_at_[hidden]> 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) <https://www.youtube.com/watch?v=SGdfPextuAU&ab_channel=CppNow>,
> particularly slide 109.
>
> –Arthur
>