This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Open status.

### 2844. Stability of `a_uniq.insert(i, j)`

Section: 22.2.6 [associative.reqmts], 22.2.7 [unord.req] Status: Open Submitter: Matt Austern Opened: 2016-12-14 Last modified: 2020-02-14

Priority: 3

View other active issues in [associative.reqmts].

View all other issues in [associative.reqmts].

View all issues with Open status.

Discussion:

If we write `a_uniq.insert(i, j)` and `[i, j)` has multiple elements with keys that compare equivalent, which ones get inserted? Consider, for example, inserting into a `map<string, int>` with

>     m.insert({{"red", 5}, {"green", 3}, {"red", 7}, {"blue", 2}, {"pink", 6}});

Which value for `"red"` will the map have?

On my implementation we got `"red" -> 5`, and I suspect that's true on most or all implementations, but I don't believe that's guaranteed by anything in the requirements. The wording in Table 90 just says that it "inserts each element from the range `[i, j)` if and only if there is no element with key equivalent to the key of that element", but that doesn't tell us what happens if `[i, j)` contains duplicate keys because it doesn't say what order the insertions are performed in. The standard should either guarantee that the first value is the one that gets inserted, or explicitly say that this is unspecified.

The same issue applies to the range constructor, and to the unordered associative containers.

[2017-01-27 Telecon]

Priority 3; Nico to provide wording.

[2020-02-14, Prague]

LWG discussion. Suggestion to specify that we like the direction of the wording for `insert` of unordered containers, but would also like to clarify that the loop is meant to be "in order" of the sequence elements.

Daniel K. volunteered to provide such wording.

Proposed resolution: