C++20中多重继承与太空船运算符的歧义问题

咱们先把核心结论说清楚：GCC的行为是符合C++标准的，Clang在这里的处理其实有偏差。你遇到的这个矛盾，本质是中缀运算符调用和显式成员函数调用的查找规则差异导致的。

为什么c < c会触发歧义？ #

你原本以为C里只有从A继承来的operator<，太空船运算符压根不该被牵扯进来——这个想法只对了一半，关键在于中缀运算符的查找规则和显式调用完全不同：

• 当你用c < c这种中缀语法时，编译器不会只找现成的operator<，它还会同时考虑通过operator<=>自动合成operator<的可能性。
• 问题就出在C同时继承了A和B的operator<=>：当编译器尝试合成operator<时，它需要调用operator<=>来完成比较，但C的对象可以隐式转换为A或B，这两个继承来的太空船运算符都能匹配，直接导致了歧义——这就是GCC报错的原因。

那显式调用c.operator<(c)为什么没问题？ #

显式调用成员函数时，编译器的查找逻辑非常直接：它只会在C的直接成员和继承成员里找operator<。C从A继承了operator<(const A&)，而C的对象可以隐式转换为const A&，所以这个函数能完美匹配，根本不会去碰太空船运算符，因此所有编译器都能通过。

为什么Clang允许c < c？ #

Clang在这里应该是做了特殊的优先级处理，优先选择了从A继承来的现成operator<，跳过了合成operator<的逻辑。但根据C++20标准的重载决议规则，现成的operator<和通过<=>合成的operator<属于不同的候选集，当合成路径出现歧义时，整个重载决议应该失败——所以GCC的行为才是严格符合标准的。

再抠一下标准细节 #

根据C++20标准中[over.match.oper]章节的规定，对于关系运算符的中缀调用，编译器必须同时考虑两类候选：

1. 显式定义的运算符成员或全局运算符
2. 通过operator<=>自动生成的运算符

当第二类候选的生成需要调用的operator<=>存在歧义时，整个重载决议就会失败，这完全对应GCC给出的错误信息。

内容的提问来源于stack exchange，提问作者Fedor