P2767R0 §3 as seen by LWG in Varna

[Quuxplusone]

LWG reviewed this wording in Varna, approved it as suitably editorial (poll 7–0–1), and we agreed that I should now submit it as a PR for @jwakely to look at.

This PR right now is structured as eight commits: two commits per container adaptor. For each adaptor, the first commit is literally the wording published in P2767R0 §3 and reviewed live in Varna. The second commit is amendments requested by LWG, to put the constructor overload sets in the traditional order (e.g. default constructor at the top). These second commits are editorial, and they're improvements over the status quo, and they were explicitly requested by LWG, but they have not been published in a P-paper, and have not been reviewed yet. Please see if they match your expectation!

Also, of course, I may have made typos in my transcription of even the first commits, so someone (@jwakely presumably) should still look through this and not just merge it blindly. Duh. :)

I expect this PR will be squash-merged with an updated commit message of some sort, and am happy to let whoever merges it figure that part out. Please let me know if you want me on my side to squash it and/or reword the commit message.

[Quuxplusone]

@jwakely : Belated ping! I bet it's too late now to get this into the draft before I submit P2767R1 based on top of it, but if I could have remembered to ping you last week, I should have...

[Quuxplusone]

I just noticed that my original upload had missed adding the text

+\pnum
+The constructors in this subclause shall not participate in overload resolution
+unless \tcode{uses_allocator_v<key_container_type, Alloc>} is \tcode{true}
+and \tcode{uses_allocator_v<mapped_container_type, Alloc>} is \tcode{true}.

at the top of [flat.multimap.cons.alloc]. This is now fixed.

[Quuxplusone]

Rebased to pick up the additions in 03da5ba (LWG3884). @jwakely ping!

[frederick-vs-ja]

@jensmaurer Why is this PR considered able to close cplusplus/papers#1539? I think P2767 is largely non-editorial.

[Quuxplusone]

@jensmaurer Why is this PR considered able to close cplusplus/papers#1539? I think P2767 is largely non-editorial.

@frederick-vs-ja You're correct, this PR absolutely would not "close" cplusplus/papers#1539, since it encompasses only one section (§3) of that whole paper. You're also correct that all the other sections are non-editorial (although some are at least non-design-level).

[Quuxplusone]

Rebased to pick up aa8a531 (typos in [flat.multiset]). @jwakely ping!

[jensmaurer]

Why is this PR considered able to close cplusplus/papers#1539? I think P2767 is largely non-editorial.

Apologies, removed.

[Quuxplusone]

@jwakely ping! (Remember we reviewed this wording in Varna?)

[Quuxplusone]

@jwakely ping, please!