问题的历史
在 C++20 之前，开发人员需要手动实现六种可排序类型的比较运算符。这种样板代码通常会在相等和排序关系之间引入细微的逻辑不一致。太空船运算符的引入是为了将这些操作整合为一个规范操作。
问题
虽然 operator<=> 减少了语法，但编译器依赖其返回类型来从 a > b 合成 b < a 的反向表达式。如果不知道排序是强、弱还是部分，编译器就无法安全地生成这些改写。
解决方案
返回类型必须是 std::strong_ordering、std::weak_ordering 或 std::partial_ordering（或隐式可转换）。这个标准类别允许编译器生成反向候选项和隐式相等检查。返回 auto 或自定义类型会禁用这种合成，从而需要手动的非对称重载。
struct Widget { int id; // 正确：启用反向候选项生成 std::strong_ordering operator<=>(const Widget&) const = default; };
场景和问题
开发针对 GPU 加速几何体的 SpatialIndex 需要一个具有严格弱排序的 BoundingBox 结构以进行 std::set 插入。箱子需要与原始坐标数组进行比较以便进行空间查询。
解决方案 1：手动运算符重载
实现十二个重载（六个用于 BoundingBox，六个用于坐标数组）提供了显式控制。然而，冗长的代码增加了 operator< 和 operator> 之间的复制粘贴错误的风险，并且在重构过程中保持一致性变得繁琐。
解决方案 2：默认太空船返回 std::weak_ordering
这从单个声明自动生成所有关系运算符。显式的返回类型允许编译器处理与坐标数组的反向比较。该实现确保了异常安全性和数学一致性，且没有样板代码。
解决方案 3：自动返回
使用 auto operator<=>(const BoundingBox&) const = default 阻止了反向候选合成。在左侧比较原始数组与右侧的 BoundingBox 时，编译失败。这种不对称破坏了空间查询接口。
决定和结果
我们选择了解决方案 2，使用 std::weak_ordering，因为边界框具有等价性（相交的框比较为相等），但没有数学上的相等性。这使得与标准算法的无缝集成成为可能，同时支持异构坐标比较。
为什么编译器从 operator<=> 合成 operator==，这个过程什么时候是不理想的？
编译器生成 operator== 为 ((*this <=> other) == 0)。这提供了一致性，但在检查相等性时强制进行全面的逐元素比较。显式地默认 operator== 允许短路评估，在第一个不同成员时立即返回 false。
将 operator<=> 定义为成员而非隐藏的友元如何破坏对称性？
成员 operator<=> 仅允许在重载解析期间对右侧操作数进行隐式转换。这种不对称性会阻止像 double == MyClass 这样的表达式编译，即使 MyClass 可以从 double 构造。使用隐藏的友元使得可以进行参数依赖查找（ADL），允许两个操作数隐式转换。
std::compare_three_way 与手动指针比较有何区别？
std::compare_three_way 为指针提供了一种在整个地址空间内一致的总排序，包括 std::nullptr_t。使用关系运算符进行手动指针比较时，在比较不相关对象时会引发未定义行为。使用标准函数对象可确保指针排序的可移植和良好定义的语义。