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.

3059. Wrong requirements for map-like associative container assignment?

Section: 23.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: