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.
Section: 21.3.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.
[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.