Прерывание изменений в C ++ 20 или регрессия в clang-trunk / gcc-trunk при перегрузке сравнения равенства с небулевым возвращаемым значением?

Следующий код прекрасно компилируется с clang-trunk в режиме c ++ 17, но прерывается в режиме c ++ 2a (предстоящий 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{});
}

Он также прекрасно компилируется с gcc-trunk или clang-9.0.0: https://godbolt.org/z/8GGT78.

Ошибка с clang-trunk и -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)

Я понимаю, что C ++ 20 сделает возможной только перегрузку, operator==и компилятор автоматически сгенерирует operator!=отрицание результата operator==. Насколько я понимаю, это работает только до тех пор, пока возвращается тип bool.

Источник проблемы заключается в том, что в Эйгене мы объявляем набор операторов ==, !=, <, ... между Arrayобъектами илиArray и скалярами, которые возвращают (выражение) массив bool(который затем может быть доступен поэлементен, или использоваться в противном случае ). Например,

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

В отличие от моего примера выше, это даже не работает с gcc-trunk: https://godbolt.org/z/RWktKs . Я еще не успел свести это к не-собственному примеру, который терпит неудачу как в clang-trunk, так и в gcc-trunk (пример вверху довольно упрощен).

Связанный отчет о проблеме: https://gitlab.com/libeigen/eigen/issues/1833

Мой актуальный вопрос: действительно ли это серьезное изменение в C ++ 20 (и есть ли возможность перегрузить операторы сравнения для возврата мета-объектов) или это более вероятно регрессия в clang / gcc?

Собственная проблема, по-видимому, сводится к следующему:

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;
}

Два кандидата на выражение

1. переписанный кандидат от operator==(const Scalar&, const Derived&)
2. Base<X>::operator!=(const Scalar&) const

Согласно [over.match.funcs] / 4 , поскольку operator!=не было импортировано в область действия Xс помощью объявления-использования , тип неявного параметра объекта для # 2:const Base<X>& . В результате # 1 имеет лучшую неявную последовательность преобразования для этого аргумента (точное совпадение, а не преобразование из производной в основание). Выбор # 1 делает программу некорректной.

Возможные исправления:

• Добавить using Base::operator!=;вDerived или
• Измените, operator==чтобы взять const Base&вместо const Derived&.

Да, код фактически ломается в C ++ 20.

Выражение Foo{} != Foo{}имеет три кандидата в C ++ 20 (тогда как в 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

Это происходит из новых переписанных правил- кандидатов в [over.match.oper] /3.4 . Все эти кандидаты являются жизнеспособными, поскольку наши Fooаргументы не являютсяconst . Чтобы найти лучшего жизнеспособного кандидата, мы должны пройти через наши тай-брейки.

Соответствующие правила для лучшей жизнеспособной функции, из [over.match.best] / 2 :

Учитывая эти определения, жизнеспособная функция F1определяется как лучшая функция, чем другая жизнеспособная функция, F2если для всех аргументов i,ICSi(F1) не хуже , чем последовательность преобразования , а затем ICSi(F2)

• [... много несоответствующих случаев для этого примера ...] или, если не это, то
• F2 - переписанный кандидат ([over.match.oper]), а F1 - нет
• F1 и F2 - переписанные кандидаты, а F2 - синтезированный кандидат с обратным порядком параметров, а F1 - нет.

#2и #3переписаны кандидаты, и #3имеет обратный порядок параметров, в то время #1как не переписан. Но для того, чтобы добраться до разрыва связей, нам нужно сначала пройти через это начальное условие: для всех аргументов последовательности преобразования не хуже.

#1Это лучше, чем #2потому, что все последовательности преобразования одинаковы (тривиально, потому что параметры функции одинаковы) и #2является переписанным кандидатом, а #1не -.

Но ... обе пары #1/ #3и #2/ #3 застряли на этом первом условии. В обоих случаях первый параметр имеет лучшую последовательность преобразования для #1/, #2а второй параметр имеет лучшую последовательность преобразования для #3(параметр, который constдолжен пройти дополнительную constквалификацию, поэтому он имеет худшую последовательность преобразования). Этаconst триггер заставляет нас не иметь возможности отдавать предпочтение ни одному из них.

В результате, полное разрешение перегрузки неоднозначно.

Насколько я понимаю, это работает только до тех пор, пока возвращается тип bool.

Это не правильно. Мы безоговорочно рассматриваем переписанных и перевернутых кандидатов. У нас есть правило из [over.match.oper] / 9 :

Если переписанный operator==кандидат выбран для разрешения перегрузки для оператора @, его тип возвращаемого значения должен быть cv bool

То есть мы еще рассматриваем этих кандидатов. Но если лучшим жизнеспособным кандидатом является operator==тот, который возвращает, скажем,Meta - результат в основном такой же, как если бы этот кандидат был удален.

Мы не хотели находиться в состоянии, когда разрешение перегрузки должно учитывать тип возвращаемого значения. И в любом случае тот факт, что код здесь возвращается, не Metaимеет значения - проблема также будет существовать, если он вернется bool.

К счастью, исправить это легко:

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

Как только вы сделаете оба оператора сравнения const, двусмысленности больше не будет. Все параметры одинаковы, поэтому все последовательности преобразования тривиально одинаковы. #1теперь будет биться #3не переписанным и #2теперь будет биться #3не обращенным - что делает #1лучшего жизнеспособного кандидата. Тот же результат, который был у нас в C ++ 17, всего несколько шагов, чтобы добраться туда.

[over.match.best] / 2 показывает, как приоритеты имеют допустимые перегрузки в наборе. Раздел 2.8 говорит нам, что F1лучше, чем F2если (среди многих других вещей):

F2является переписанным кандидатом ([over.match.oper]) и F1не является

Пример там показывает явный operator<вызов, даже если operator<=>он есть.

И [over.match.oper] /3.4.3 говорит нам, что кандидатура operator==в этом случае является переписанным кандидатом.

Однако ваши операторы забывают одну важную вещь: они должны быть constфункциями. И не делая их, constв игру вступают более ранние аспекты разрешения перегрузки. Ни одна из функций является точным соответствием, так как не- const-До-const преобразования должны произойти для различных аргументов. Это вызывает неоднозначность в вопросе.

Как только вы их сделаете const, Clang trunk компилирует .

Я не могу говорить с остальной частью Eigen, так как я не знаю код, он очень большой, и поэтому не может вписаться в MCVE.

У нас есть похожие проблемы с нашими заголовочными файлами Goopax. Компиляция следующего с clang-10 и -std = c ++ 2a приводит к ошибке компилятора.

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);
}

Предоставление этих дополнительных операторов, кажется, решает проблему:

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);
};