【テクニカル・上級編】Null安全と『共変性（Covariance）』の衝突：List<dynamic>を安全に扱うための境界線 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

Dartの「型安全」を揺るがす共変性の陥穽：Null安全を堅牢に維持する境界線

DartのSound Null Safetyは、コンパイル時に静的解析を行うことで、実行時の`NoSuchMethodError: method ‘…’ called on null`を撲滅した。しかし、Dartの型システムには、オブジェクト指向言語としての柔軟性を担保するために組み込まれた「共変性（Covariance）」という、古くからの設計上の「妥協点」が潜んでいる。

我々ランタイムエンジニアから見れば、この共変性は型安全性の防壁を容易に突破するバックドアになり得る。今回は、`List`や`List`が、いかにしてNull安全の境界を侵食し、ランタイムの整合性を破壊するのかを低レイヤの視点から解き明かす。

—

1. なぜ「共変性」がNull安全をすり抜けるのか

Dartにおいて、ジェネリクスはデフォルトで共変である。つまり、`List`は`List`のサブタイプとして扱われる。これは直感的には正しく見えるが、以下のコードを見てほしい。

void main() {
List strings = [‘dart’, ‘vm’];
List objects = strings; // 共変性によりキャストが成功

objects.add(null); // 型システム上、objectsはListなのでnull追加が可能

// 実行時：stringsの中身は [‘dart’, ‘vm’, null] となっている
// 静的解析では strings[0].length は安全に見えるが、実行時に爆発する
print(strings[0].length);
}

内部構造の崩壊

Dart VMのメモリレイアウト上、`List`は参照の連続領域である。`objects.add(null)`が実行された瞬間、VMは型チェックをバイパスし、メモリ上のポインタを書き換える。

コンパイラは`List`に対して、「このリストにはStringしか入らない」という仮定で最適化（インライン化やレジスタ割り当て）を行うことがある。この「仮定」と「メモリの実態」が乖離した瞬間、プログラムは未定義動作に近い状態に陥る。これが、Dartにおける型安全の防壁を突破する典型的な攻撃ベクトルである。

—

2. 防御的設計：型安全を強制する「イミュータブル・ビュー」

この問題を回避する最も洗練された方法は、「可変な共変型を外部に公開しない」ことだ。ライブラリ設計において、`List`をそのまま戻り値として渡すのは、セキュリティ上の脆弱性を放置しているに等しい。

推奨されるラッパー実装

Dartの`UnmodifiableListView`を活用し、コンパイル時と実行時の両面で防御を固める。

import ‘dart:collection’;

class SafeBuffer {
final List _internal = [];

// 外部にはイミュータブルなビューのみを公開
List get view => UnmodifiableListView(_internal);

void add(T item) {
// ここでTがnull許容でない場合、nullチェックが強制される
_internal.add(item);
}
}

void main() {
final buffer = SafeBuffer();
buffer.add(“Hello”);

// buffer.view.add(null); // コンパイルエラー：UnmodifiableListViewは追加を許さない
}

このアプローチの肝は、VMのヒープ領域における参照の整合性を維持することにある。`UnmodifiableListView`は、元のリストへのアクセスを委譲する際、書き込みメソッドをオーバーライドして`UnsupportedError`をスローする。これにより、ランタイムでの不正なポインタ操作を確実に阻止できる。

—

3. シニアエンジニアが意識すべき「イベントループの整合性」

非同期処理（`Future`や`Stream`）が絡むと、この問題はさらに複雑化する。`Isolate`間でデータをやり取りする際、`TransferableTypedData`以外のオブジェクトは複製されるか、あるいは参照が共有される。

`List`をIsolate間で投げると、受信側での型推論が甘くなる傾向がある。以下は、型安全性を維持するための「防壁」の極致である。

// 型の完全性を担保するキャスト・バリデーター
List castOrThrow(dynamic input) {
if (input is List) {
return input.cast(); // Dartの強力なキャストメカニズムを利用
}
throw ArgumentError(‘Type mismatch: Expected List<$T>‘);
}

この`cast()`メソッドは、単なるキャストではない。実行時にリスト内の全要素を走査し、`T`に適合するかを確認する「実行時の型アサーション」である。パフォーマンスとのトレードオフだが、セキュリティと整合性が最優先される境界領域では必須のコストだ。

—

結論：型システムは「信じるもの」ではなく「定義するもの」

DartのNull安全は強力だが、それはあくまで「コンパイラが静的に追跡可能な範囲」に限られる。Dart VMの柔軟性、すなわち共変性というレガシーが、時として我々の意図せぬ形でメモリを汚染する。

Listを安易に渡すな。 常に`List`へと具体化し、境界で型チェックを行え。
不変性を強制せよ。 `UnmodifiableListView`や`built_collection`のようなイミュータブルな抽象化レイヤーは、単なるコードスタイルではなく、防御的プログラミングの要諦である。
ランタイムの挙動を想像せよ。 あなたが書いたその一行が、VMのどのメモリ領域を書き換え、どのIsolateのコンテキストを汚染するのか。

Dartを掌握するということは、VMの動的な挙動を静的な型システムでいかに飼いならすかという、終わりのない知的な格闘である。この極限の知見を、諸君の次なるアーキテクチャに刻み込むことを期待する。