Rustコンパイラは、相互整合性システムのコアコンポーネントである孤立ルールを強制し、各トレイト-型ペアが依存グラフ全体で最大1つの実装を持つことを保証します。このルールは、実装されるトレイトまたは実装を受ける型のいずれかが現在のクレート内で定義されている場合にのみ有効とされるimplブロックを要求します。トレイトと型の両方が外部である場合、Rustは同じターゲットに対して矛盾する実装を導入する可能性を防ぎ、それは未定義の動作や下流プロジェクトにおける解決不能な曖昧さを引き起こすことになります。「ローカル型」の例外は、開発者がローカル型に対して外部トレイトを実装したり、外部型に対してローカルトレイトを実装したりすることを許可し、明確な単純化とランタイムディスパッチテーブルなしのゼロコスト抽象化を保証します。
私たちのチームは、スキーマ定義をJSONにシリアライズする必要がある高性能なGraphQLサーバライブラリを構築していました。私たちはローカルSchema構造体に対してserdeのSerializeトレイトを実装する必要がありましたが、これは型がローカルであったため簡単でした。しかし、Document型に対してカスタムフォーマットが必要で、これは外部のgraphql_parserクレートから取得し、標準のDisplayトレイトを介してロギングシステムに統合するためでした。これにより、DocumentとDisplayの両方が外部であるため、将来のクレートが独自のDisplay実装を追加した場合、利用者に対して調和違反を引き起こす可能性があり、設計上の緊張が生じました。
私たちが最初に考えた解決策は、Newtypeパターンで、graphql_parser::Documentをタプル構造体struct DocWrapper(graphql_parser::Document)でラップし、DocWrapperでDisplayを実装することでした。
このアプローチは孤立ルールを完全に尊重します。なぜなら、DocWrapperはローカル型であり、Rustが新しい型のためにランタイムオーバーヘッドなしでゼロコスト抽象化を保証するからです。これにより、APIの完全な管理が可能になり、将来の上流の競合が防止されます。ただし、この方法は変換のために相当なボイラープレートを導入し、ユーザーがインスタンスを手動でラップしたり、提供されたFrom実装に依存したりする必要があり、実装の詳細が漏れたラッパー型でパブリックAPIが混雑する可能性があります。
2つ目の解決策は、私たちのクレート内でローカルに定義された拡張トレイトGraphQLDisplayを作成し、それを外部Document型に直接実装することでした。
これも孤立ルールの下では合法です。なぜなら、トレイト自体はローカルであっても、型は外部であり、ラッパー型のエルゴノミクスの摩擦を回避し、メソッドチェーン構文を可能にします。重要な欠点は、これがRustの標準フォーマットマクロ（例えばformat!やprintln!）と統合されないことです。これらは特にDisplayトレイトを要求しているため、ユーザーはカスタムトレイトをインポートし、特定のメソッドを呼び出す必要があり、標準のRustの慣習とは一致しない分断された体験を生じます。
結局、私たちはDocument型にはNewtypeパターンを選びました。これは、長期的な安定性と標準ライブラリとの統合が短期的なエルゴノミクスコストを上回ると判断したからです。DocWrapperを使用することで、エラーロギングはカスタムマクロやトレイトインポートなしで標準のフォーマットツールを使用できることが保証されました。Schema型については、型と導出マクロの両方がローカルであったため、そのままSerializeを導出しました。その結果、すべてのトレイト解決がコンパイル時に明確で、コンパイルは曖昧な解決のオーバーヘッドなしに高速に保たれ、graphql_parserが独自のDisplay実装を導入してもダイヤモンド依存の問題のリスクを排除しました。
孤立ルールは、Vec<T>のようなジェネリック型にどのように適用され、なぜVec<LocalType>に対して外部トレイトを実装することが許可されている一方で、Vec<ForeignType>は禁じられているのですか？
孤立ルールはジェネリック型において「ローカル型カバレッジ」の概念を通じて適用されます。これは、ジェネリック構造内の少なくとも1つの型パラメータが現在のクレートにローカルである必要があることを要求します。したがって、impl ForeignTrait for Vec<LocalType>は有効です。なぜなら、LocalTypeが実装をローカルクレートに固定し、その特定の具体型に対して他のクレートが競合する実装を書くことができないことを保証するからです。対照的に、impl ForeignTrait for Vec<ForeignType>はルールに違反します。なぜなら、トレイトとすべての型引数が外部であるため、ForeignTypeを定義しているクレートが後に同じトレイトをVec<ForeignType>に対して実装する可能性があるためです。候補者は、このカバレッジがネストされたジェネリックに再帰的に適用されるが、ジェネリックコンテナ自体には適用されないことを見逃しがちです。コンテナもローカルで定義されている場合を除いて。
なぜ、上流クレートでの“impl<T> Trait for T where T: ToString”のようなブランク実装が、下流クレートが特定の型に対してそのトレイトを実装するのを防ぐのですか。ローカルな場合でも？
ブランク実装は、特定のトレイト境界を満たすすべての型にデフォルトの動作を提供します。Rustの整合性ルールは、既存のブランク実装と重複するような具体的な実装を禁止します。もし上流クレートがimpl<T> Serialize for T where T: ToStringを提供すると、下流クレートはToStringを実装する任意の型に対してSerializeを実装できなくなります。たとえその型がローカルであってもです。なぜなら、コンパイラはブランク実装と具体的な実装が相互に排他的であることを保証できないからです。これは孤立ルールとは異なります。孤立ルールは誰が実装を書くかを制御しますが、重複ルールは、二つの有効な実装が同じ名前空間に共存できるかどうかを制御します。候補者はよくこれらの概念を混同し、孤立ルールの下で構文的に有効である具体的な実装を記述しようとしますが、上流のブランク実装との重複のために却下されます。
Fn、FnMut、およびFnOnceのような基本的トレイトに対して孤立ルールが特別に扱われるのはなぜであり、これによりクロージャが整合性を違反せずにこれらのトレイトを実装できるのはなぜですか？
Fnトレイトファミリーは「基本的」として指定されており、トレイトのジェネリックパラメータにローカル型が含まれる場合、外部型に対するこれらのトレイトの実装を許可するために孤立ルールを緩和します。この「逆転ルール」は、実装が許可されているかどうかを判断する際に、トレイトを整合性目的でローカルとして扱います。たとえば、あなたのクレートで定義されたクロージャは、あなたのクレートにローカルなユニークで名前のない型を持っており、このクロージャに対してFnOnceを実装することが許可されています。これはFnOnceが標準ライブラリで定義されており、クロージャの型が不透明であるにもかかわらずです。候補者はこのメカニズムを見逃すことが多いですが、これはRustがクロージャを扱う方法の実装の詳細であり、これを理解することで、クロージャがローカルな環境をキャプチャし、外部トレイトを実装できる理由が明らかになります。新しい型のラッパーを必要とせず、整合性エラーを引き起こすことなく。