Proposed resolution:

Resolved by acceptance of N4387.

[ 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

[ 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.

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.