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.