`<flat_meow>`: Should move constructors use the `extract() &&` member function?

[vmichal]

Followup to the discussion of Stephan T. Lavavej (@StephanTLavavej) and Alex Guteniev (@AlexGuteniev) at https://discord.com/channels/737189251069771789/1120873380615295027/1449085881079169194
with goal of clarifying the decision

"If we change flat_set's move assign to use extract() like flat_map does, libcxx\test\std\containers\container.adaptors\flat.multiset\flat.multiset.cons\move_assign.pass.cpp fails because they have a squirrelly container that has (implicitly) deleted copy/move ctors. I think this fails the sequence container requirements so the test is bogus." We could leave this as-is, but it might be worth investigating upstream.

In my humble opinion, using extract is not desirable. The pattern _STD move(_Other).extract(); seems reasonable when constructing a new object due to guaranteed copy elision, but it constructs an unnecessary temporary when used in operator=. Although extract() elegantly solves the self-assignment problem, I believe if (this != _STD addressof(_Other)) is not worse.

A minimal example for experiments https://godbolt.org/z/7744YMxGb shows the difference between the two implementations.

I have speculatively implemented the fix in #5990, among other things. I wanted to revisit this question to clarify the chosen solution.

[StephanTLavavej]

I think I'm fine with avoiding extract().

[vmichal]

Fixed by the linked PR.