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: 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: