[associative.reqmts.general],[unord.req.general] Fix cross-references to [container.alloc.reqmts] and [container.reqmts]

[CaseyCarter]

Both paragraphs incorrectly point to [container.reqmts] instead of [container.alloc.reqmts] for "the requirements of an allocator-aware container".

Both paragraphs state "the requirements placed on value_type in [container.alloc.reqmts] apply instead to key_type and mapped_type" for map, multimap, set, and multiset. This would be nonsense, since those containers never allocate or (or allocator-construct) key_type or map_type objects: do allocator-construct value_type objects. The examples in each paragraph also make the error obvious: there are no CopyAssignable requirements in [container.alloc.reqmts].

I suspect these pairs of xrefs in each paragraph were transposed sometime in the past and we just haven't noticed.

[cjdb]

We may want to defer this to LWG first: I don't see any other wording that prohibits map<K&, V> (but that has issues), and it would be strange to allow map<K&&, V>, but not any of map<K&, V>, unordered_map<K&, V>, or unordered_map<K&&, V>. It might also be worth raising whether we want to continue supporting cv-qualified key_types, especially since MapLike<K const, V> is the same as MapLike<K, V>, but with additional instantiations.

[jwakely]

I suspect these pairs of xrefs in each paragraph were transposed sometime in the past and we just haven't noticed.

Yes, d09a77e fixed another case of this.

And dd32b7e, and 4fac9f9

The subclause [container.alloc.requirements] was added by 93ff092, before that they didn't have their own subclause, so referring to [container.reqmts] was correct.

[CaseyCarter]

We may want to defer this to LWG first: I don't see any other wording that prohibits map<K&, V> (but that has issues), and it would be strange to allow map<K&&, V>, but not any of map<K&, V>, unordered_map<K&, V>, or unordered_map<K&&, V>. It might also be worth raising whether we want to continue supporting cv-qualified key_types, especially since MapLike<K const, V> is the same as MapLike<K, V>, but with additional instantiations.

Changing "the requirements placed on value_type in [container.alloc.reqmts] apply instead to key_type and mapped_type" to "the requirements placed on value_type in [container.reqmts] apply instead to key_type and mapped_type" doesn't affect this. The first requirement on value_type in [container.reqmts] is:

typename X::value_type

-2- Result: T
-3- Preconditions: T is Cpp17Erasable from X (see [container.alloc.reqmts], below).

which still implicitly requires value_type* to be a valid type, and therefore key_type* and map_type*. This still forbids key_type and map_type to be reference types just as effectively as before. It's not terribly explicit - and like I said seems silly, since containers don't pass pointers of those types to Allocator::construct and Allocator::destroy - but swapping these cross-references doesn't change this property.

[cjdb]

Thanks for clarifying!