On Mon, Apr 10, 2023 at 11:59 AM LoS via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> Introduction of value_equal to
> std::unordered_map / std::unordered_multimap
>
> I. Motivation
> The std::map / std::multimap containers already provides a value_compare
> member class that
> allows to compare two value_type objects using the key_compare comparison
> object under
> the hood. This allows the user to directly call an instance of the
> value_compare comparison
> object and thus perform a compare operation between two value_type objects
> easily.
>

More importantly, it allows us to cleanly express the class invariant
    assert(std::is_sorted(v.begin(), v.end(), v.value_comp()));
which is true for all associative containers (set, multiset, map, multimap,
flat_set, flat_multiset, flat_map, flat_multimap).
I don't see any such benefit to the proposed `value_eq`.

At best it would let you write
    assert(std::is_uniqued(v.begin(), v.end(), v.value_eq()));
for (unordered_set, unordered_map).
But in that case, I would expect the proposal to also:
- Consider adding the `std::is_uniqued` algorithm to <algorithm>
- Consider adding the `value_equal` member type and `value_eq` member
function to (set, map, flat_set, flat_map), where it would be implemented
in terms of two calls to `value_compare`

Also note that you're going to get bikeshedding over the choice between
`equal/eq` and `equivalent/equiv`. The advantage of the latter is that it's
technically correct; the disadvantage is that it's more of a mouthful.

IMHO, this is not worth pursuing. But if you pursue any part of it, IMHO
`std::is_uniqued` will turn out to be the actually useful part. (Sure it's
redundant with `std::adjacent_find`; but so is `std::contains` redundant
with `std::find`, and `std::none_of` redundant with `std::find_if`. Having
cleanly defined verbs is nice.)

HTH,
Arthur