【テクニカル・上級編】Dartの共変性（Covariance）とNull安全：List<dynamic>が引き起こす実行時エラーの回避術 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dartの共変性が招く「静的な欺瞞」と、Null安全を貫く型設計の深淵

Dartの型システムは「Sound Null Safety」の導入により、静的解析の段階で多くの脆弱性を封じ込めることに成功した。しかし、VMの心臓部を覗けば、そこには依然として共変性（Covariance）という強力かつ危険な「例外」が存在する。

多くのエンジニアが `List` や `List` を不用意に使い、コンパイラの裏をかこうとして実行時に `TypeError` を叩き出す。なぜDartは、型安全性を犠牲にしてまで共変性を許容するのか。そして、我々はどう防壁を構築すべきか。

今日は、Dartランタイムの挙動を解剖し、型システムの「隙間」を埋めるための極限の設計指針を提示する。

—

1. 共変性という「パンドラの箱」

Dartにおいて、ジェネリクスはデフォルトで共変である。つまり、`List` は `List` のサブタイプとして扱われる。これは直感的には正しく見えるが、ランタイムにおいて「型汚染」の温床となる。

void pollute(List list) {
// コンパイル時は成功するが、ランタイムの型チェックを潜り抜ける可能性がある
list.add(42);
}

void main() {
List strings = [‘dart’, ‘vm’];
// List は List のサブタイプとみなされる
pollute(strings);

print(strings[2]); // 実行時エラー: type ‘int’ is not a subtype of type ‘String’
}

なぜこれが起きるのか。Dart VMはメモリ効率のため、コレクションに対して「書き込み時の型チェック」を遅延評価する戦略を採っている。`pollute` 関数が `List` を受け取った瞬間、そのポインタは「何でも入る箱」として認識される。しかし、実体は依然として `List` のメモリ領域を指している。「箱の定義」と「メモリの制約」が乖離した瞬間、ランタイムは破壊される。

2. Null安全と共変性の衝突

Null安全下では、`List` に `null` を代入することは許される。しかし、`List` に `null` を混入させる行為は、たとえ `List` にキャストしたとしても、言語仕様の根幹を揺るがす行為だ。

この挙動を制御し、ランタイムエラーを未然に防ぐには、「コレクションのイミュータブル化」と「型パラメータの不変（Invariant）化」の二重防壁が必要となる。

回避術：`List` を隠蔽するラッパーパターン

Listの共変性を断ち切るには、Dartのジェネリクスの挙動を制御する `typedef` や、ファクトリーコンストラクタによるインターフェース分離が有効だ。

/// 共変性を排除した「型厳密なラッパー」
abstract class ReadOnlyList {
T operator [](int index);
int get length;
}

class SafeList implements ReadOnlyList {
final List _data;
SafeList(this._data);

@override
T operator [](int index) => _data[index];

@override
int get length => _data.length;
}

このように、書き込み操作を剥奪し、読み取り専用のインターフェースを通すことで、`List` として渡された際の型汚染をインターフェース層で遮断できる。これは単なるコードの整理ではない。VMの命令パイプラインが実行する「型チェック」のコストを、開発者が意図したタイミングに強制的に引き寄せる最適化である。

3. メモリとIsolateを貫く型防壁

Isolateを跨いだデータの受け渡しにおいても、この共変性の罠は潜んでいる。`SendPort` を介してデータを送信する際、Dartは `TransferableTypedData` を使わない限り、内部的にコピーが発生する可能性がある。

もし、不完全な型定義のままリストを送信した場合、受信側のIsolateがデシリアライズを行う瞬間に `TypeError` がスローされる。これはイベントループを停止させ、メインスレッドのクラッシュを招く。

セキュリティ研究者的防衛策

1. `List` の全面禁止: Linter設定で `avoid_dynamic_calls` を有効にするだけでは不十分。`List` さえも「防壁」として扱い、必ず `cast()` を通して型を厳格に再定義してから処理を開始せよ。
2. `covariant` キーワードの慎重な使用: Dartにはメソッド引数に `covariant` を付与する機能があるが、これは「サブクラスで型を広げることができる」という宣言である。セキュリティを重視する設計では、これを使用せず、コンストラクタで型を確定させる不変クラス（Immutables）を強制すべきである。

結論：ランタイムを「信じない」ためのアーキテクチャ

Dartのコンパイラは、コードの記述者よりも賢い。しかし、記述者が意図的に「共変性の隙間」を利用して型をぼかした場合、ランタイムエンジンはそれを検知するまでの間、無防備なメモリ領域をさらけ出すことになる。

シニアエンジニアに求められるのは、「DartはNull安全だから大丈夫」という甘美な言葉を捨て、VMの型チェックがいつ、どこで発生するかを脳内で完全にエミュレートすることだ。

型安全とは、コンパイラに守ってもらうものではない。あなたが設計するクラスのインターフェースが、如何にランタイムの曖昧さを許容しないか。その厳格さの中にのみ、堅牢なアプリケーションは宿る。

次は、AOTコンパイル時における「型推論の消失」が、JIT実行時とどれほどのパフォーマンス格差を生むのか、その深淵を解剖することにしよう。