¿Cambio de ruptura en C ++ 20 o regresión en clang-trunk / gcc-trunk cuando se sobrecarga la comparación de igualdad con el valor de retorno no booleano?

El siguiente código se compila bien con clang-trunk en el modo c ++ 17 pero se rompe en el modo c ++ 2a (próximo c ++ 20):

// Meta struct describing the result of a comparison
struct Meta {};

struct Foo {
    Meta operator==(const Foo&) {return Meta{};}
    Meta operator!=(const Foo&) {return Meta{};}
};

int main()
{
    Meta res = (Foo{} != Foo{});
}

También se compila bien con gcc-trunk o clang-9.0.0: https://godbolt.org/z/8GGT78

El error con clang-trunk y -std=c++2a:

<source>:12:19: error: use of overloaded operator '!=' is ambiguous (with operand types 'Foo' and 'Foo')
    Meta res = (f != g);
                ~ ^  ~
<source>:6:10: note: candidate function
    Meta operator!=(const Foo&) {return Meta{};}
         ^
<source>:5:10: note: candidate function
    Meta operator==(const Foo&) {return Meta{};}
         ^
<source>:5:10: note: candidate function (with reversed parameter order)

Entiendo que C ++ 20 hará posible solo sobrecargar operator==y el compilador generará automáticamente operator!=al negar el resultado de operator==. Por lo que yo entiendo, esto solo funciona mientras el tipo de retorno sea bool.

La fuente del problema es que en Eigen declaramos un conjunto de operadores ==, !=, <, ... entre Arrayobjetos o Arrayy escalares, que devuelven (una expresión de) una matriz de bool(que luego se puede acceder elemento a elemento, o utilizado de otra manera ) P.ej,

#include <Eigen/Core>
int main()
{
  Eigen::ArrayXd a(10);
  a.setRandom();
  return (a != 0.0).any();
}

En contraste con mi ejemplo anterior, esto incluso falla con gcc-trunk: https://godbolt.org/z/RWktKs . Todavía no he logrado reducir esto a un ejemplo que no sea Eigen, que falla tanto en clang-trunk como en gcc-trunk (el ejemplo en la parte superior está bastante simplificado).

Informe de problema relacionado: https://gitlab.com/libeigen/eigen/issues/1833

Mi pregunta real: ¿es esto realmente un cambio radical en C ++ 20 (y existe la posibilidad de sobrecargar los operadores de comparación para devolver Metaobjetos), o es más probable una regresión en clang / gcc?

El problema de Eigen parece reducirse a lo siguiente:

using Scalar = double;

template<class Derived>
struct Base {
    friend inline int operator==(const Scalar&, const Derived&) { return 1; }
    int operator!=(const Scalar&) const;
};

struct X : Base<X> {};

int main() {
    X{} != 0.0;
}

Los dos candidatos para la expresión son

1. el candidato reescrito de operator==(const Scalar&, const Derived&)
2. Base<X>::operator!=(const Scalar&) const

Por [over.match.funcs] / 4 , como operator!=no fue importado en el alcance de Xmediante una declaración de uso , el tipo del parámetro de objeto implícito para # 2 es const Base<X>&. Como resultado, el # 1 tiene una mejor secuencia de conversión implícita para ese argumento (coincidencia exacta, en lugar de la conversión derivada a base). Al seleccionar # 1, el programa se vuelve mal formado.

Posibles soluciones:

• Agregar using Base::operator!=;a Derivedo
• Cambiar el operator==a tomar un const Base&lugar de una const Derived&.

Sí, el código de hecho se rompe en C ++ 20.

La expresión Foo{} != Foo{}tiene tres candidatos en C ++ 20 (mientras que solo había uno en C ++ 17):

Meta operator!=(Foo& /*this*/, const Foo&); // #1
Meta operator==(Foo& /*this*/, const Foo&); // #2
Meta operator==(const Foo&, Foo& /*this*/); // #3 - which is #2 reversed

Esto proviene de las nuevas reglas de candidatos reescritas en [over.match.oper] /3.4 . Todos esos candidatos son viables, ya que nuestros Fooargumentos no lo son const. Para encontrar el mejor candidato viable, tenemos que pasar por nuestros desempates.

Las reglas relevantes para la mejor función viable son, desde [over.match.best] / 2 :

Dadas estas definiciones, una función viable F1se define como una mejor función que otra función viable F2si, para todos los argumentos i, no es una secuencia de conversión peor que , y luego ICSi(F1)ICSi(F2)

• [... muchos casos irrelevantes para este ejemplo ...] o, si no eso, entonces
• F2 es un candidato reescrito ([over.match.oper]) y F1 no es
• F1 y F2 son candidatos reescritos, y F2 es un candidato sintetizado con un orden inverso de parámetros y F1 no es

#2y #3son candidatos reescritos, y #3ha invertido el orden de los parámetros, mientras #1que no se reescribe. Pero para llegar a ese desempate, primero debemos superar esa condición inicial: para todos los argumentos, las secuencias de conversión no son peores.

#1es mejor que #2porque todas las secuencias de conversión son iguales (trivialmente, porque los parámetros de la función son iguales) y #2es un candidato reescrito mientras #1no lo es.

Pero ... ambos pares #1/ #3y #2/ #3 quedan atrapados en esa primera condición. En ambos casos, el primer parámetro tiene una mejor secuencia de conversión para #1/ #2mientras que el segundo parámetro tiene una mejor secuencia de conversión #3(el parámetro que constdebe someterse a una constcalificación adicional , por lo que tiene una secuencia de conversión peor). Este constflip-flop hace que no podamos preferir ninguno de los dos.

Como resultado, toda la resolución de sobrecarga es ambigua.

Por lo que yo entiendo, esto solo funciona mientras el tipo de retorno sea bool.

Eso no es correcto Consideramos incondicionalmente candidatos reescritos y revertidos. La regla que tenemos es, desde [over.match.oper] / 9 :

Si operator==se selecciona un candidato reescrito por resolución de sobrecarga para un operador @, su tipo de retorno será cv bool

Es decir, todavía consideramos a estos candidatos. Pero si el mejor candidato viable es operator==aquel que regresa, digamos, Metael resultado es básicamente el mismo que si ese candidato fuera eliminado.

Nos hicieron no queremos estar en un estado donde la resolución de sobrecarga tendría que considerar el tipo de retorno. Y, en cualquier caso, el hecho de que el código aquí regrese Metaes irrelevante; el problema también existiría si regresara bool.

Afortunadamente, la solución aquí es fácil:

struct Foo {
    Meta operator==(const Foo&) const;
    Meta operator!=(const Foo&) const;
    //                         ^^^^^^
};

Una vez que realiza ambos operadores de comparación const, no hay más ambigüedad. Todos los parámetros son iguales, por lo que todas las secuencias de conversión son trivialmente iguales. #1ahora vencería #3no reescribiendo y #2ahora vencería #3al no revertirse, lo que lo convierte en #1el mejor candidato viable. El mismo resultado que tuvimos en C ++ 17, solo unos pocos pasos más para llegar allí.

[over.match.best] / 2 enumera cómo se priorizan las sobrecargas válidas en un conjunto. La Sección 2.8 nos dice que F1es mejor que F2si (entre muchas otras cosas):

F2es un candidato reescrito ([over.match.oper]) y F1no es

El ejemplo allí muestra un operator<ser explícito llamado aunque operator<=>esté allí.

Y [over.match.oper] /3.4.3 nos dice que la candidatura de operator==en esta circunstancia es un candidato reescrito.

Sin embargo , sus operadores olvidan una cosa crucial: deberían ser constfunciones. Y hacer que no constcausen que los aspectos anteriores de la resolución de sobrecarga entren en juego. Ninguna de las funciones es una coincidencia exacta, ya que las conversiones no const-a- constnecesitan suceder para diferentes argumentos. Eso causa la ambigüedad en cuestión.

Una vez que los hagas const, compila el tronco Clang .

No puedo hablar con el resto de Eigen, ya que no conozco el código, es muy grande y, por lo tanto, no cabe en un MCVE.

Tenemos problemas similares con nuestros archivos de encabezado Goopax. Compilar lo siguiente con clang-10 y -std = c ++ 2a produce un error de compilación.

template<typename T> class gpu_type;

using gpu_bool     = gpu_type<bool>;
using gpu_int      = gpu_type<int>;

template<typename T>
class gpu_type
{
  friend inline gpu_bool operator==(T a, const gpu_type& b);
  friend inline gpu_bool operator!=(T a, const gpu_type& b);
};

int main()
{
  gpu_int a;
  gpu_bool b = (a == 0);
}

Proporcionar estos operadores adicionales parece resolver el problema:

template<typename T>
class gpu_type
{
  ...
  friend inline gpu_bool operator==(const gpu_type& b, T a);
  friend inline gpu_bool operator!=(const gpu_type& b, T a);
};