PiotrNycz's questions

Tenho um caso em que o tipo struct não precisa ser padrão operator<=>- só que nem todos os campos são importantes ao definir a ordem dos objetos.

struct A
{
    int a;
    int b; // not important when ordering
    int c;

    constexpr std::strong_ordering operator<=>(const A& rhs) const
    {
        if (const auto res = a<=>rhs.a; res != 0) return res;
        return c<=>rhs.c;
    }
};

Para minha surpresa, não posso usar container com esse tipo como argumento para std::ranges::sort:

std::array<A, 100> aa{};
std::ranges::sort(aa);

Eu verifiquei no mais novo gcc (14) e clang (19) e ele basicamente afirma que o intervalo não é classificável porque std::invocable_v<std::ranges::less&, A&, A&>não é verdade. Veja o link godbold

Mais observações:

1. Funciona com std::sort( std::sort(aa.begin(), aa.end());)
2. Funciona ao adicionar não padrãooperator==
3. E funciona com o padrão ( =default)operator<=>

Isso é um bug do compilador, um bug padrão do C++ ou alguma regra estranha do C++ está em jogo aqui e deveria ser assim? Se a última opção estiver correta - você pode fornecer uma justificativa para tal comportamento?

Atualizar:

Pelos comentários parece que std::ranges::less{}(A{}, A{})requer não apenas operator<(derivado de operator<=>), mas também operator==que não pode ser derivado de não padrão, operator<=>então o erro.

Mas uma questão permanece: por que std::ranges::lessas necessidades operator==?

E melhor exemplo dos comentários: link

Ao usar apenas ponteiros/referências para std::variant<T...>definir de T...onde parte de T é declarada apenas para frente - tenho esse problema que não consigo nem usar ponteiros nem referências para isso std::variant- porque suas classes bases queriam ser instanciadas - e exigem std::is_default_constructibleoutras características.

Veja código de exemplo:

#include <variant>

struct A;
struct B;
using AB = std::variant<A,B>;
AB* ab();

template <typename T>
void usePointer(T*){}


int main() {
    // fails to compile because std::variant gets instantiated here!
    usePointer(ab());
}

Para simplificar o exemplo - isto é o que acontece como vejo:

struct A;
struct B;

template <typename T>
void usePointer(T*){}


template <bool> class SomeBase {};

template <typename T>
struct Some : SomeBase<std::is_default_constructible_v<T>>
{};

Some<A>* someA(); 

int main() {
    // this will not compile - because  this
    // SomeBase<std::is_default_constructible_v<T>>
    // does not compile - because A is unknown
    usePointer(someA());
}

/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/type_traits: In instantiation of 'constexpr const bool std::is_default_constructible_v<A>':
<source>:12:29:   required from 'struct Some<A>'
   12 | struct Some : SomeBase<std::is_default_constructible_v<T>>
      |                        ~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~
<source>:21:23:   required from here
   21 |     usePointer(someA());
      |                       ^
/opt/compiler-explorer/gcc-14.1.0/include/c++/14.1.0/type_traits:3385:54: error: invalid use of incomplete type 'struct A'
 3385 |   inline constexpr bool is_default_constructible_v = __is_constructible(_Tp);
      |                                                      ^~~~~~~~~~~~~~~~~~~~~~~
<source>:3:8: note: forward declaration of 'struct A'
    3 | struct A;
      |        ^
Compiler returned: 1

Todos os 3 compiladores (gcc, clang, msvc) se comportam/rejeitam da mesma maneira - veja: https://godbolt.org/z/5cjf1Pv4d

A pergunta: isso está correto? Para mim, isso é realmente um bug - seja nas implementações dos compiladores ou no padrão - porém não consigo encontrar nada no padrão que exija esse comportamento.

O "engraçado" é que quando o modelo de classe também é declarado adiante - tudo funciona. Quero dizer - este código é aceito por todos os compiladores:

struct A;

template <typename T>
void usePointer(T*){}

template <typename T> struct Some;

Some<A>* someA(); 

int main() {
    usePointer(someA());
}