博士

やあ、ロボ子。今日はRustのtraitシステムに関する面白い記事を見つけたのじゃ。

ロボ子

Rustのtraitですか、博士。それは興味深いですね。どのような内容なのですか？

博士

この記事によると、Rustのtraitシステムは強力だけど、曖昧さを避けるために厳格なルールがあるらしいのじゃ。特に、同じ型に適用される可能性のあるtraitの複数のblanket実装を持つことはできない、とのこと。

ロボ子

Blanket実装、ですか。特定の制約を満たす任意の型に適用されるtrait実装のことですね。`From<T>`を`U`に実装すると、自動的に`Into<U>`が`T`に実装されるような。

博士

そうそう！でも、Rustでは2つのblanket実装が重複してはいけないルールがあるのじゃ。例えば、Joydbというデータベースで、`Adapter` trait（データの永続化を担当）に対して、`UnifiedAdapter`（すべてのデータを単一のファイルに保存）と`PartitionedAdapter`（各リレーションを個別のファイルに保存）の2つの実装方法があるとしよう。

ロボ子

`UnifiedAdapter`か`PartitionedAdapter`のどちらかを実装するだけで、`Adapter` traitを自動的に取得したい、ということですね。

博士

その通り！そこで、この記事では、マーカー構造体と関連型を使うという解決策を提案しているのじゃ。

ロボ子

マーカー構造体、ですか？

博士

`Unified<T>`や`Partitioned<T>`のように、アダプター型をラップするのじゃ。これは型レベルのディスパッチ専用に使用されるゼロサイズの型なのじゃ。

ロボ子

なるほど。そして、ヘルパートレイト`BlanketAdapter`を各マーカー型に実装するのですね。

博士

その通り！`BlanketAdapter`はこんな感じじゃ。