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

### 2397. `map<K, V>::emplace` and explicit `V` constructors

Section: 20.15.8.7 [meta.trans.other] Status: Resolved Submitter: Peter Dimov Opened: 2014-06-12 Last modified: 2015-05-05

Priority: 1

View all other issues in [meta.trans.other].

View all issues with Resolved status.

Discussion:

Please consider the following example:

>     #include <map>
>     #include <atomic>

>     int main()
>     {
>        std::map<int, std::atomic<int>> map_;

>        map_.emplace(1, 0);  // fail
>        map_.emplace(1);     // fail
>        map_.emplace(1, {}); // fail

>        map_.emplace(std::piecewise_construct,
>            std::tuple<int>(1), std::tuple<>()); // OK
>     }

The first three calls represent attempts by an ordinary programmer (in which role I appear today) to construct a map element. Since `std::atomic<int>` is non-copyable and immovable, I was naturally drawn to `emplace()` because it constructs in-place and hence doesn't need to copy or move. The logic behind the attempts was that `K=int` would be constructed from '`1`', and `V=std::atomic<int>` would be (directly) constructed by '`0`', default constructed, or constructed by '`{}`'.

Yet none of the obvious attempts worked.

I submit that at least two of the three ought to have worked, and that we have therefore a defect in either `map::emplace` or `pair`.

Ville:

There exists a related EWG issue for this.

Daniel:

If the proposal N4387 would be accepted, it would solve the first problem mentioned above.

[2015-02, Cologne]

AM: I think Peter's expectation is misguided that the second and third "//fail" cases should work.
DK: Howard's paper [note: which hasn't been written yet] will make the second case work... AM: ...but the third one will never work without core changes.

Case 1 is solved by DK's paper, cases 2 and 3 are not defects; at best they are extensions.

[2015-05, Lenexa]

STL: think this is covered with N4387
MC: this was accepted in Cologne
STL: only want to fix the first emplace
MC: leave alone and mark as closed by N4387

Proposed resolution:

Resolved by acceptance of N4387.