This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of New status.
Section: 24.2 [container.requirements] Status: New Submitter: Richard Smith Opened: 2018-02-05 Last modified: 2018-02-14
Priority: 3
View all other issues in [container.requirements].
View all issues with New status.
Discussion:
What are the requirements for
a = b;
... where a and b are of map-like associative container type (map, multimap, unordered_map, unordered_multimap)?
The general container requirements say just:r = a // Postconditions: r == a
(Incidentally, earlier in the table, there is a clear error: the general container requirements permit "a = rv" for assignment from an rvalue, but "a" here is a potentially-const container. Oops.) Oddly. there are no requirements at all on T here.
The allocator-aware container requirements add:a = t // Requires: T is CopyInsertable into X and CopyAssignable.
... where T is the container's value_type, that is, pair<const key_type, mapped_type>. Note that such a pair is not CopyAssignable for "normal" key types that disallow assignment to const objects. They also add:
a = rv // Requires: if !POCMA, T is MoveInsertable into X and MoveAssignable.
... which has the same problem in the !POCMA case.
The associative container requirements and unordered associative container requirements have a similar problem for assignment from an initializer list:a = il // Requires: value_type is CopyInsertable into X and CopyAssignable.
Presumably these assignments are intended to actually work, but what are the intended constraints? Do we wish to allow implementations to perform node reuse for these map-like containers? Presumably yes, and if so, the key_type portion of the node must be assigned as well as the value_type portion (for instance, with whatever implementation technique is used to power node_handle) as we cannot assume that key equivalence (or, for unordered_*map, even key equality) implies substitutability.
I think, then, that the associative container requirements and unordered associative container requirements should specify different requirements for the "a = t", "a = rv", and "a = il" for the map-like containers; specifically:for "a = t" and "a = il", we should require that value_type is CopyInsertable into X, and key_type and mapped_type are CopyAssignable
for "a = rv", if !POCMA, we should require that value_type is MoveInsertable into X and key_type and mapped_type are MoveAssignable
(And we should fix the general container requirements to constrain "r = rv", not "a = rv".)
Daniel: The "a = rv" problematic is already handled by LWG 3028.[2018-02-13, Priority set to 3 after mailing list discussion]
Proposed resolution: