C++ std::map named requirements allocator-aware container

Question

Currently I'm trying to convert some of C++'s named requirements to C++20 concepts (https://godbolt.org/z/EdY5d6319 still highly WIP!). However, I stumpled upon a problem.

Given the final C++20 working draft (http://open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4861.pdf):

• page 790: requirements for an allocator-aware container:
  Given an allocator-aware container X with value_type T the expression a == t where a denotes a non-const lvalue of type X and t an lvalue or const rvalue of type X is required.
  Preconditions: T is Cpp17CopyInsertable into X and Cpp17CopyAssignable.
  -> Therefore, X::value_type must be CopyAssignable.
• page 699: is_copy_assignable:
  "For a referenceable type T, the same result as is_assignable_v<T&, const T&>, otherwise false."
• page 849: std::map:
  "A map meets all of the requirements of a container, of a reversible container (22.2), of an associative container (22.2.6), and of an allocator-aware container (Table 76)."

So std::map<Key, T> meets the requirements of an allocator-aware container. Therefore, std::map<Key, T>::value_type must be CopyAssignable. However, std::map<Key, T>::value_type is defined as std::pair<const Key, T>, which is not CopyAssignable due to Key beeing const. Therefore, std::map does not meet the allocator-aware container requirements, which contradicts page 849 in the standard draft.

What do I miss here?

Answer 1

There's an explicit carve out for this case in [containers.associative.reqmts]/7:

The associative containers meet all the requirements of Allocator-aware containers, except that for map and multimap, the requirements placed on value_­type in Table 76 apply instead to key_­type and mapped_­type. [ Note: For example, in some cases key_­type and mapped_­type are required to be Cpp17CopyAssignable even though the associated value_­type, pair<const key_­type, mapped_­type>, is not Cpp17CopyAssignable. — end note ]