一貫性のないRust

このブログ記事の執筆において、LLM（大規模言語モデル）は一切使用されていません。

成長が停滞したエコシステム

Rust エコシステムは、その発展方法に根本的な問題を抱えています。

• serde

  などの基盤クレートは、

  Serialize

  といった基礎的なトレイトを定義します。
  これらのトレイトを利用したいクレートは、自分の型に対して実装しなければなりません。
  実装が提供されない場合、その型を下流でシリアライズできなくなります。

• serde

  の代替（例：

  nextserde

  ）が公開されたとすると、

  serde

  をサポートするすべてのクレートは

  nextserde

  にも対応しなければならず、
  新しいシリアライズライブラリを追加していくことは非現実的であり、クレート作者にとって大きな負担になります。
• クレートユーザーが新しいシリアライズライブラリを使いたい場合、
  すべての関連クレートをフォークし

  nextserde

  をサポートするように修正せざるを得ません。
  この結果、基盤となるクレート（例えば

  serde

  ）への代替が生まれたとしても、それがエコシステム全体に広がりにくくなります。

「最初に登場した」古いクレートが、より優れた代替が存在していても残ってしまう強いインセンティブがあります。
これはライブラリや Rust 開発者の責任ではなく、言語自体の coherence（整合性）と orphan rules（孤立ルール） によってエコシステムに課せられたものです。

coherence（整合性）

coherence は「ある型について、あるトレイトは最大で一度だけ実装できる」ということを保証します。

trait Trait {}

trait Thingies {}
trait OtherThingies {}

impl<T: Thingies> Trait for T {}
impl<T: OtherThingies> Trait for T {} // ← error[E0119]

また、orphan rules は「トレイト実装は、そのトレイトか自分自身の型が現在のクレートで定義されている場合に限り書ける」という制約です。

// crate a
pub trait Trait {}
pub struct Foo;

// crate b
use a::*;
impl Trait for Foo {} // ← error[E0117]

なぜ coherence が必要なのか？

HashMap の問題

// crate a
#[derive(PartialEq, Eq)]
pub struct MyData(u8);

// crate b
impl Hash for MyData { /* ... */ }
pub fn make_hashset() -> HashSet<MyData> { /* ... */ }

// crate c
impl Hash for MyData { /* different implementation */ }
pub fn check_hashset(set: HashSet<MyData>) { /* ... */ }

// crate d
c::check_hashset(b::make_hashset());

1 つのクレートで作った

HashSet

Hash

Soundness（安全性）

// crate a
impl Trait for () {
    type Assoc = *const u8;
}
pub fn make_assoc() -> <() as Trait>::Assoc { /* ... */ }

// crate b
impl Trait for () {
    type Assoc = Box<u8>;
}
fn drop_assoc(a: <() as Trait>::Assoc) { /* ... */ }

// crate c
b::drop_assoc(a::make_assoc()); // unsafe transmute

同じトレイトに対して異なる型の実装が重なっていると、コンパイラが衝突を検知できず、未定義動作につながります。

orphan rules（孤立ルール）

coherence は安全性に不可欠ですが、orphan rules が ほぼ 必要なのは次の理由です。

• これがないと、2 つのクレートが同じトレイトを同じ型に対して実装し、重複が発生する可能性があります。
  コンパイラはそれを検知できなくなります。
• 動的ライブラリとしてビルドされたライブラリをリンク時に内容を知らずに組み込むことも可能になりますが、その際にも重複実装がないかを保証する必要があります。

既存の提案

#[fundamental]

#[marker]

coherence を除去することの利点

coherence を完全に取り除けば、以下の問題が消える可能性があります。

名前付き実装とトレイト境界パラメータ

trait Trait<T> {}
impl Name<T> = Trait<T> for T { }

この構文を使うことで、トレイト境界は「名前付き実装」を参照して明示的に満たすことができます。

fn function<T: Trait + OtherTrait>(x: T) -> T
where
    (): Five,
{
    /* ... */
}

非整合性トレイト

トレイトを「非整合性」化し、孤立ルールから除外することも可能です。

pub incoherent trait Serialize {
    fn serialize(&self) -> String;
}

これにより、複数のクレートが同じ型に対して異なる

Serialize

再考：なぜ coherence が重要なのか

HashMap の問題（再検討）

• Hash

  ,

  Eq

  ,

  PartialEq

  を整合性トレイトとして残す（現状維持）。
• あるいは、非整合性にし、

  HashMap<K, V>

  内で境界を入れる。

  struct HashMap<K: Hash + Eq, V> { /* ... */ }
  

  これにより、同じ

  HashMap

  インスタンス内ではハッシュ/等価が一貫します。

Soundness（安全性）の再検討

名前付き実装を使うと、どの実装が使用されているか明示的に確認できます。

// crate a
impl ATrait = Trait for () { type Assoc = *const u8; }

// crate b
impl BTrait = Trait for () { type Assoc = Box<u8>; }

let a_assoc: a::ATrait::Assoc = a::make_assoc(); // 型不一致でエラーになる
b::drop_assoc(a_assoc);

これにより、

a_assoc

drop_assoc

結論

「実装（impl）を値として扱い、名前付きにして明示的に選択できるようにする」ことで、次の利点があります。

• 非整合性トレイト をサポート可能
• ライフタイム依存特殊化の安全な実現が期待できる
• 型システムの安全性を強固に保証できる
• コンテキスト／能力を自然に表現できる

このモデルへコンパイラを移行するには大きな工数が必要です（例：2026 年 Rust Dictionary Passing Style Experiment）。同時に、以下のような言語設計上の決断も慎重に検討しなければなりません。

1. 名前付き実装とそれらを渡すための構文
2. 外部型へのトレイト導出を楽にするエルゴノミックサポート
3. トレイト境界を型定義へ移行するマイグレーション戦略
4. この複雑さが正当化されるかどうかの評価

coherence は確かに貴重な機能でしたが、エコシステム進化という課題は依然として大きいです。
「非整合性 Rust」へ移行すること（単なる回避策ではなく本質的な改善）で、多くの問題を解決できる可能性があります。