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.

2052. Mixup between mapped_type and value_type for associative containers

Section: 24.2.7 [associative.reqmts] Status: Resolved Submitter: Marc Glisse Opened: 2011-05-04 Last modified: 2016-01-28

Priority: 2

View other active issues in [associative.reqmts].

View all other issues in [associative.reqmts].

View all issues with Resolved status.

Discussion:

(this is basically reopening the first part of issue 2006, as discussed in the thread starting at c++std-lib-30698 )

Section 24.2.7 [associative.reqmts]

In Table 102, several uses of T (which means mapped_type here) should be value_type instead. This is almost editorial. For instance:

a_uniq.emplace(args)

Requires: T shall be EmplaceConstructible into X from args.

Effects: Inserts a T object t constructed with std::forward<Args>(args)... if and only if there is no element in the container with key equivalent to the key of t. The bool component of the returned pair is true if and only if the insertion takes place, and the iterator component of the pair points to the element with key equivalent to the key of t.

[ 2011 Bloomington ]

Not even an exhaustive list of problem locations. No reason to doubt issue.

Pablo agrees to provide wording.

[ 2011-09-04 Pablo Halpern provides improved wording ]

[2014-02-15 post-Issaquah session : move to Resolved]

AJM to replace this note with a 'Resolved By...' after tracking down the exact sequence of events, but clearly resolved in C++14 DIS.

Proposed resolution:

In both section 24.2.7 [associative.reqmts] Table 102 and 24.2.8 [unord.req], Table 103, make the following text replacements:

[ Notes to the editor: The above are carefully selected phrases that can be used for global search-and-replace within the specified sections without accidentally making changes to correct uses T. ]