Created on 2018-11-27.00:00:00, last changed 2018-12-21.15:26:00.
[ 2018-12-21 Reflector prioritization ]
Set Priority to 2
After acceptance of P0919R3 into the new working draft (N4791), it is possible that an unordered container's member type key_equal is different from its template argument for Pred (the former being Hash::transparent_key_equal while the latter being std::equal_to<Key>). However, it is unclear which is stored in the container and used as the predicate in this case.In particular, [unord.req]/4 says:
[…] The container's object of type Pred — denoted by pred — is called the key equality predicate of the container.
In Table 70, the row for X::key_equal places requirements to Pred and not to Hash::transparent_key_equal:
Requires: Pred is Cpp17CopyConstructible. Pred shall be a binary predicate that takes two arguments of type Key. Pred is an equivalence relation.
The specification of operator== and operator!= in [unord.req]/12 uses Pred:
[…] The behavior of a program that uses operator== or operator!= on unordered containers is undefined unless the Pred function object has the same behavior for both containers and the equality comparison function for Key is a refinement(footnote 227) of the partition into equivalent-key groups produced by Pred.
The exception safety guarantees in [unord.req.except] mentions "the container's Pred object" twice.The noexcept-specifiers of unordered containers' move assignment operator and swap member function are all in terms of Pred. I think the intent is to make Hash::transparent_key_equal override Pred. If that's true, then all the abovementioned uses of Pred in the specification should probably be changed to uses key_equal.
|2018-12-21 15:26:00||admin||set||messages: + msg10265|