質問の歴史
C++20以前は、開発者はソート可能な型のために6つの比較演算子を手動で実装していました。このボイラープレートは、等価性と順序関係の間に微妙な論理的不一致を引き起こすことがよくありました。宇宙船演算子が導入され、これらを1つの標準的な操作に統合することができました。
問題
**operator<=>**は構文を減らす一方で、コンパイラはその戻り値の型に依存して、b < aをa > bから合成するようにします。順序が強い、弱い、または部分的かどうかがわからなければ、コンパイラはこれらの書き換えを安全に生成できません。
解決策
戻り値の型は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: 手動演算子オーバーロード
12のオーバーロード（BoundingBox用に6つ、座標配列用に6つ）を実装することで明示的な制御が提供されました。しかし、冗長さは**operator<とoperator>**の間でのコピーペーストエラーのリスクを引き起こし、リファクタリング中の一貫性を維持するのが面倒でした。
解決策2: std::weak_orderingを返すデフォルトの宇宙船演算子
これにより、単一の宣言から自動的にすべての関係演算子が生成されました。明示的な戻り値の型により、コンパイラは座標配列に対して逆の比較を処理することができました。この実装は例外安全性と数学的一貫性を保証し、ボイラープレートをゼロにしました。
解決策3: Auto戻り値
auto operator<=>(const BoundingBox&) const = defaultを使用すると、逆候補の合成が妨げられました。生の配列を左側に、BoundingBoxを右側に比較すると、コンパイルに失敗しました。この非対称性は空間クエリインターフェースを壊しました。
決定と結果
我々は、境界ボックスが相互に交差するボックス（比較すると等しい）を持ちますが、数学的な等価性は持たないため、std::weak_orderingを使用した解決策2を選びました。これにより、標準アルゴリズムとのシームレスな統合が可能になり、異なる座標の比較をサポートしました。
なぜコンパイラはoperator<=>からoperator==を合成するのか、そしてそれはいつ最適でないのか？
コンパイラは**operator==**を((*this <=> other) == 0)として生成します。これは一貫性を提供しますが、等価性をチェックする際に完全な要素ごとの比較を強制します。operator==を明示的にデフォルト化することで、短絡評価を可能にし、最初の異なるメンバーで即座にfalseを返します。
なぜoperator<=>を隠れた友人ではなくメンバーとして定義することで対称性が壊れるのか？
メンバーのoperator<=>は、オーバーロード解決中の右側のオペランドでのみ暗黙の変換を許可します。この非対称性により、MyClassがdoubleから構築可能であっても、double == MyClassのような式がコンパイルできなくなります。隠れた友人を使用すると、引数依存型探索（ADL）を可能にし、両方のオペランドが暗黙的に変換できるようになります。
std::compare_three_wayと手動ポインタ比較の違いは何ですか？
std::compare_three_wayは、std::nullptr_tを含む全アドレス空間にわたって一貫したポインタの全順序を提供します。手動のポインタ比較は、無関係なオブジェクトを比較する際に未定義の動作を引き起こします。標準関数オブジェクトを使用することで、ポインタソートのための可搬性があり、良く定義された意味論を保証します。