`<flat_map>`: unclear resolution of LWG-3963 "Different `flat_(multi)map` specializations should be able to share same nested classes"

[vmichal]

I've found old LWG issue "Different std::flat_map/std::flat_multimap specializations should be able to share same nested classes" (LWG-3963) submitted by A. Jiang (@frederick-vs-ja).
I'm a little confused about the resolution - the status indicates that it's still open, however, the wording suggests that someone called it not-a-defect and thus threw it off the table.

The standard clearly uses nested struct for containers, but I see reasons why shared struct could be better.
Either way (tested on Godbolt, https://godbolt.org/z/K34P54nPE) the following static assertion passes for both trunk libc++ and libstdc++ but fails on our feature branch.

static_assert(!std::is_same_v<std::flat_map<int, int>::containers, std::flat_multimap<int, int>::containers>);

Any thoughts?

Relevant for completion of #2910.

[frederick-vs-ja]

LWG-3963 is already speculatively implemented in MSVC STL, perhaps due to my suggestion in #2910 (comment). I submitted this LWG issue mainly for legitimating that idea, which possibly saves throughput a bit.

[vmichal]

I have no objections against this decision. However, if we think this is the final decision (until the committee says otherwise), I will make #2910 track this as well for completeness. I am using that issue as a hub to track progress on STL's request to

Double-check that all LWG issues are implemented, possible we overlooked them as they were voted in after feature branch creation

[StephanTLavavej]

Although it's still open, LWG doesn't sound very keen on the idea of accepting LWG-3963's proposed resolution.

I think we should avoid implementation divergence and undo this speculative implementation. I think the throughput impact is unobservable, and certainly not enough to justify a departure from our baseline of Do What The Standard Says (TM).

[vmichal]

Fixed by the linked PR