Related to #6020 but IMO should be considered separately. Mostly a mirroring of LLVM-175086.
In flat_map and flat_set, sometimes we call unique with a synthesized equivalence relation to deduplicate elements after sorting. And it's probably redundant to call the comparator twice when deduplicating the sorted range.
When operator== is reliable, we can just use it for unique (addressed in #6024).
When it's not reliable, I think it will be better to
- introduce a modified version of
unique which doesn't require equivalence relation, and
- pass something similar to
key_compare to that algorithm to deduplicate elements.
Moreover, it turns out that key-equiv in the standard wording is possibly pointless. It's unclear to me whether the current wording requires particular side effects from synthesized equivalence comparisons. If so, we should also file an LWG issue to get rid of such requirements.
Related to #6020 but IMO should be considered separately. Mostly a mirroring of LLVM-175086.
In
flat_mapandflat_set, sometimes we calluniquewith a synthesized equivalence relation to deduplicate elements after sorting. And it's probably redundant to call the comparator twice when deduplicating the sorted range.When
operator==is reliable, we can just use it forunique(addressed in #6024).When it's not reliable, I think it will be better to
uniquewhich doesn't require equivalence relation, andkey_compareto that algorithm to deduplicate elements.Moreover, it turns out that
key-equivin the standard wording is possibly pointless. It's unclear to me whether the current wording requires particular side effects from synthesized equivalence comparisons. If so, we should also file an LWG issue to get rid of such requirements.