std::variant::operator< chamada inesperada para conversão bool implícita. Varia entre os padrões

Heh, eu sabia exatamente qual seria esse código quando li o título. Não consigo encontrar um grande alvo ingênuo, então tentarei fazer desta a resposta canônica.

C++17

Em C++ 17, std::variant(como vários outros modelos de classe na biblioteca padrão, std::pair, std::tuple, e std::optionalentre eles) define <em termos de adiamento aos tipos subjacentes' <. A única operação invocada no tipo subjacente foi T.

Especificamente, o que operator<faria em dois objetos do tipo variant<T, U>(assumindo <que foi definido para ambos Te U) é primeiro comparar os índices e, se forem iguais, comparar os valores. Algo assim:

bool operator<(variant<T, U> const& lhs, variant<T, U> const& rhs) {
    if (lhs.index() != rhs.index()) {
        return lhs.index() < rhs.index();
    }
   
    // not this specifically, but this conceptually
    return std::get<lhs.index()>(lhs) < std::get<rhs.index()>(rhs);
}

C++20

O C++ 20 foi introduzido <=>, que geralmente é uma maneira muito melhor de lidar com pedidos e traz muitas conveniências para facilitar a escrita de comparações (igualdade e ordem). Mas também surgiu o problema de nenhum código anterior ao C++ 20 estar <=>disponível. Portanto, não podemos vender apenas std::varianta comparação de use <=>porque nenhum código existente usa <=>.

Em vez disso, a biblioteca usa preferencialmente, <=>mas recorre <se <=>não estiver disponível. Isso é feito com um objeto somente de especificação chamado synth-three-way, especificado em [expos.only.entity] :

  constexpr auto synth-three-way =                 // exposition only
    []<class T, class U>(const T& t, const U& u)
      requires requires {
        { t < u } -> boolean-testable;
        { u < t } -> boolean-testable;
      }
    {
      if constexpr (three_way_comparable_with<T, U>) {
        return t <=> u;
      } else {
        if (t < u) return weak_ordering::less;
        if (u < t) return weak_ordering::greater;
        return weak_ordering::equivalent;
      }
    };

É bastante simples: se <=>estiver disponível, realmente queremos usar o <=>. Mas se <=>não estiver disponível, voltamos ao que tínhamos que fazer em C++ 17 e usamos <.

E isso tem o comportamento que você deseja.

Exceto quando... isso não acontece.

Vejamos seu tipo:

struct Foo {
    int x;
    int y;

#ifndef DROP_CAST_OP
    constexpr operator bool() const { return x || y; }
#endif

#ifdef USE_SPACESHIP
    constexpr auto operator<=>(const Foo&) const noexcept = default;
#else
    friend constexpr bool operator<(const Foo& a, const Foo& b) noexcept
    {
        return a.x < b.x || (a.x == b.x && a.y < b.y);
    }
#endif
};

Podemos passar por vários comportamentos. Presumo aqui que sempre fornecemos exatamente um de <ou <=>:

Tenha em mente que a regra é: se <=> funciona , use <=>, caso contrário, volte para <. Porém, não temos um mecanismo na linguagem para verificar como <=> funciona.

Quando você fornece um <=>para comparar os Foos, então <=>existe e é viável e é a melhor opção, por isso não é surpresa que seja usado.

Quando você fornece um <para comparar os Foos, isso por si só não significa necessariamente que <=>não seja viável. Quando você fornece uma conversão implícitabool para , então f1 <=> f2ainda é viável - ela é avaliada como (bool)f1 <=> (bool)f2porque os candidatos internos estão disponíveis. Isso não é específico para bool- qualquer tipo interno (como intou char const*) ou outro tipo para o qual o ADL possa encontrar um candidato levaria ao mesmo comportamento. Portanto, de acordo com a linguagem, comparar dois Foos com <=>funciona perfeitamente - esse é o mecanismo que preferimos na biblioteca. Só que neste caso específico dá um comportamento surpreendente, já que você provavelmente preferiu o explícito <ao implícito <=>por meio da boolconversão implícita.

É por isso que marcar o operador de conversão explícito resolve o problema - o builtin operator<=>(bool, bool)não é mais um candidato viável, portanto não há maneira viável de invocar <=>dois Foos. Portanto, a biblioteca volta a usar <.

Observe que este não é um problema novo. Se Footivesse fornecido uma conversão implícita para bool, mas nem an operator<nem a operator<=>, mesmo em C++ 17 a variantcomparação ainda funcionaria: por meio da conversão implícita para bool. Porque avaliar t < useria uma expressão válida por meio dessa conversão. A única novidade aqui é que, devido à priorização de <=>, mesmo fornecer an <não garante que a biblioteca use o operador de comparação que você escreveu.

Esse é um problema que sempre surge, porque as pessoas escrevem tipos que possuem operadores de comparação explícitos (via <), mas também fornecem uma função de conversão implícita para um tipo que possui um builtin <=>. Qualquer mecanismo de biblioteca que detecte a presença de <=>fornecerá um falso positivo aqui, e a única solução é fornecer <=>você mesmo um explícito ou tornar a função de conversão explicitem vez de implícita.

Se tivéssemos um mecanismo de linguagem para descobrir o que especificamente t <=> uinvocado (e há um proposto em P2825 ), então poderíamos adicionar validação adicional de que apenas selecionamos <=>se t <=> ue t < usão viáveis ​​e invocamos o mesmo tipo de coisa (ou seja, que ambos invocam o mesmo operator<=>ou se este invocar uma função chamada operator<que ambas as funções recebam os mesmos tipos de parâmetros). Mas até que isso aconteça, tome cuidado com funções de conversão implícitas na presença de <=>.