Date: Fri, 12 Feb 2021 21:49:21 +0200
Hi All,
If a class has a user-defined operator <=>, but no other comparison operators,
specifically, no operator ==, then the operator <=> of tuples and containers
will quietly fall back to the (auto-generated) operator <, in the end still
invoking operator <=> but up to twice as many times as necessary.
This is because synth-three-way (http://eel.is/c++draft/expos.only.func) is
defined as only using <=> if three_way_comparable_with is satisfied, which
requires _all_ the comparison operators.
Is it intentional that std::tuple<X>::operator <=> should be so averse to
using X::operator <=>?
I’m aware that defining operator <=> but not operator == is contrary to best
practices, but silent pessimization does not seem to be an adequate
punishment.
If a class has a user-defined operator <=>, but no other comparison operators,
specifically, no operator ==, then the operator <=> of tuples and containers
will quietly fall back to the (auto-generated) operator <, in the end still
invoking operator <=> but up to twice as many times as necessary.
This is because synth-three-way (http://eel.is/c++draft/expos.only.func) is
defined as only using <=> if three_way_comparable_with is satisfied, which
requires _all_ the comparison operators.
Is it intentional that std::tuple<X>::operator <=> should be so averse to
using X::operator <=>?
I’m aware that defining operator <=> but not operator == is contrary to best
practices, but silent pessimization does not seem to be an adequate
punishment.
-- WBR Roman.
Received on 2021-02-12 13:49:35