This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of Resolved status.
Container::key_equal
differs from Pred
Section: 23.2.8 [unord.req] Status: Resolved Submitter: S. B. Tam Opened: 2018-11-27 Last modified: 2020-01-13
Priority: 2
View other active issues in [unord.req].
View all other issues in [unord.req].
View all issues with Resolved status.
Discussion:
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.
[…] The container's object of type
Pred
— denoted bypred
— 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 typeKey
.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 thePred
function object has the same behavior for both containers and the equality comparison function forKey
is a refinement(footnote 227) of the partition into equivalent-key groups produced byPred
.
The exception safety guarantees in [unord.req.except] mentions "the container's Pred
object" twice.
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 Reflector prioritization]
Set Priority to 2
[2020-01 Resolved by the adoption of P1690 in Belfast.]
Proposed resolution: