質問への回答

C++20では、浮動小数点型を非型テンプレートパラメータ（NTTP）として導入し、構造型として分類しました。標準に従って（[temp.type]/4）、2つの非型テンプレート引数は、両者が同等である場合にのみ一致します。浮動小数点値の場合、同等性は値の等しさではなく、ビット単位の同一性によって決定されます。つまり、2つの浮動小数点定数は、オブジェクト表現が同一で（すべてのビットが一致する）場合にのみ同じテンプレート引数として扱われます。

その結果、+0.0と**-0.0は、IEEE 754表現の下で符号ビットのみが異なるため、異なるテンプレートをインスタンス化します。同様に、異なるNaNペイロードも異なる型を生成します。これは、+0.0 == -0.0がtrue**に評価されるランタイムの動作とは対照的です。なぜなら、等号演算子は数学的な同等性を実装している一方で、テンプレートメカニズムは物理的同一性を要求するからです。

実生活からの状況

私たちは、物理シミュレーションエンジンのコンパイル時次元解析ライブラリを構築している際にこれに遭遇しました。私たちは物理定数（例えば重力定数）を表すためにdouble NTTPを使用し、理論上のゼロ質量の場合（0.0として表現）にソルバーを特化させたいと考えていました。しかし、質量中心を評価するいくつかのconstexpr計算が特定の算術演算（例えば-1.0 * 0.0）を通じて-0.0を生成しました。

ユーザーがこれらの計算の結果をテンプレート引数として渡すと、コンパイラは私たちのZeroMass専門化の代わりに一般的な実装を選択し、一般的なバージョンがアイデンティティ行列を返す代わりに完全な行列逆行列を実行するため、40％のパフォーマンス低下を引き起こしました。

私たちは3つの解決策を検討しました。第一に、+0.0と-0.0の両方に対して明示的に特化することができます。このアプローチは正しい動作を保証しましたが、メンテナンスの負担を倍増させ、異なるNaN表現や丸め誤差のために異なるビットパターンを持つ実質的にゼロの値を処理することはできませんでした。

第二に、符号ビットをゼロに強制するconstexprヘルパー関数を使用して、すべての入力をノーマライズすることを検討しました（例えば、value == 0.0 ? 0.0 : value）。この解決策はゼロには堅牢でしたが、すべてのテンプレートインスタンスにラッパーマクロを必要とし、APIを汚染し、直接のパラメータ渡しを期待しているユーザーを混乱させました。

第三に、私たちはif constexprおよびstd::bit_castを使用して、メタ関数のエントリポイントで値を正準化する型ノーマライゼーションレイヤを実装し、すべてのゼロを正のものとして扱い、静かなNaNを正準ペイロードに統合しました。この解決策を選んだ理由は、ライブラリ利用者に透明性を提供しつつ、内部的一貫性を確保できたからです。

実装後、ライブラリはすべての浮動小数点NTTPをビット表現によって扱うことを文書化しました。これによりパフォーマンス問題が解決されましたが、開発者には-0.0と+0.0が型システムにおいて異なる構成状態であることを認識する必要がありました。

候補者がしばしば見落とすこと

なぜstd::is_same_v<decltype(func<+0.0>()), decltype(func<-0.0>())>は+0.0 == -0.0がtrueであるときにfalseと評価されるのか？

テンプレートインスタンス化はOne Definition Ruleおよび正確なテンプレート引数の一致に依存します。コンパイラがfunc<+0.0>()に遭遇すると、浮動小数点リテラルのビットパターンをハッシュまたは比較します。IEEE 754では、-0.0は符号ビットがセットされているのに対し、+0.0はそうでないため、コンパイラは2つの異なる定数値を見て、2つの異なる関数インスタンスを生成します。ランタイムでの等号演算子は、符号付きゼロが等しいと比較されるIEEE 754仕様を実装していますが、テンプレートの仕組みはランタイムの意味が適用される前にオブジェクト表現のレベルで機能します。候補者は、値が数学的に同等であるため、同じ型を生成すべきだと仮定することが多く、ランタイムの値のセマンティクスとコンパイル時の型の同一性を混同しています。

なぜtemplate<float F> struct S{}; S<1.0>は通常の式では1.0が暗黙にfloatに変換可能であるにもかかわらず、コンパイルに失敗するのか？

浮動小数点型の非型テンプレートパラメータについて、C++20標準ではテンプレート引数がパラメータと正確に同じ型であることを明示的に要求しています。標準の浮動小数点昇格および変換は許可されていません（[temp.arg.nontype]/5）。リテラル1.0の型はdoubleであり、floatに直接バインドできないため、float Fにバインドできません。floatサフィックスを使用する必要があります：S<1.0f>。この制限は、テンプレートのマングリングと型の同一性が変換精度の損失なしに明確な表現を必要とするために存在します。初心者はこれを見落としがちですが、関数呼び出しは変換を許可しますが、テンプレートは変換ルールが考慮される前に正確な型マッチングを実行します。

異なる静かなNaN（qNaN）ペイロードは、すべて「数値ではない」を表すときにテンプレートインスタンス化にどのように影響するのか？

IEEE 754ではNaN値がペイロードビット（診断情報）を持つことを許可します。C++20のテンプレート同等性はビット単位の比較を使用するため、異なるペイロードを持つ2つのNaN（例えば、異なるハードウェアでのstd::numeric_limits<double>::quiet_NaN()と0.0/0.0の結果）は異なるテンプレート引数となります。これは、異なるNaNビットパターンに対してテンプレートをインスタンス化する場合、コードの膨張を引き起こす可能性があるか、プログラマーが唯一の専門化であると仮定していたものに対して異なる翻訳単位が異なるNaN表現を観察する場合、微妙なODR違反を引き起こす可能性があります。候補者はしばしばNaNがnullptrのような単一の値であると仮定しますが、実際には各ビットパターンがテンプレートシステムで異なることを表します。