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

3691. Replacement of keys in associative containers

Section: 24.2.7.1 [associative.reqmts.general], 24.2.8.1 [unord.req.general] Status: New Submitter: Jens Maurer Opened: 2022-04-19 Last modified: 2022-05-17

Priority: 3

View other active issues in [associative.reqmts.general].

View all other issues in [associative.reqmts.general].

View all issues with New status.

Discussion:

Keys for elements of associative containers are presented as const subobjects, preventing their modification by user code according to 9.2.9.2 [dcl.type.cv] p4.

However, that does not prevent those keys to be transparently replaced, for example via

std::map<int, int> map;
map.emplace(1, 2);
using KT = std::map<int, int>::key_type;
auto it = map.begin();
it->first.~KT();
new (const_cast<int*>(&it->first)) KT(3);

This, of course, breaks the ordering of the keys, and should be undefined behavior.

Related issue: CWG 2514.

[2022-05-17; Reflector poll]

Set priority to 3 after reflector poll. One vote for NAD.

Proposed resolution:

This wording is relative to N4910.

1. Modify 24.2.7.1 [associative.reqmts.general] as indicated:

   -5- For set and multiset the value type is the same as the key type. For map and multimap it is equal to pair<const Key, T>. Ending the lifetime of the key subobject of a container element by means other than invoking a member function of the container results in undefined behavior.

2. Modify 24.2.8.1 [unord.req.general] as indicated:

   -7- For unordered_set and unordered_multiset the value type is the same as the key type. For unordered_map and unordered_multimap it is pair<const Key, T>. Ending the lifetime of the key subobject of a container element by means other than invoking a member function of the container results in undefined behavior.