【テクニカル・上級編】DartのNull安全と「Future/Stream」の非同期処理における型定義 – Dart コア文法・オブジェクト指向・Null安全解析バイブル

境界線の再定義：Dartの型システムにおける Null許容型と非同期ストリームの深淵

DartのSound Null Safetyは、単なる「Nullポインタ例外の回避策」ではない。それは、コンパイル時に型グラフのトポロジーを静的に確定させ、ランタイムにおけるメモリの安全性を保証するための、極めて強力な「静的解析器とVMの契約」である。

特に非同期処理、すなわち`Future`や`Stream`を扱う際、開発者は「型パラメータのどこに`?`を置くか」という些細な差異が、ランタイムのイベントループとメモリレイアウトにどう影響するかを理解しなければならない。

今日は、`Stream`と`Stream?`の決定的な違いを、VMの内部挙動を交えて解体する。

—

1. 型の配置が握る「意味論（Semantics）」の正体

まず、この2つの型定義がコンパイラ（`dart2js` や `dart2wasm`、あるいは `AOT`）に対してどのような命令を下しているのかを定義する。

A. `Stream` : 「データの内容が欠損する可能性」

これはストリームのイベントが「値」を持つか「Null」を持つかという、データの値の範囲に関する定義である。
コンパイラは、`StreamSubscription`が発火するたびに、そのペイロードが `T` 型であるか、あるいは `null` であるかを動的に判別しなければならない。

B. `Stream?` : 「パイプライン自体の存在」

これは、ストリームのインスタンスそのものがNullである可能性を指す。
つまり、購読しようとした瞬間に `NullPointerException` (Dartでは `NoSuchMethodError`) が発生するリスクを、型システムが静的に警告している状態だ。

—

2. メモリとイベントループの視点から見る挙動

`Stream` の場合：値のボックス化と型の昇格

`Stream`において、もし `T` がプリミティブ（`int`など）であれば、内部的には `null` を許容するために、VMはそれらをオブジェクトとしてボックス化する。
これはメモリ消費の観点からは微細なコストだが、高頻度なイベントループ内では無視できない。

// コンパイラは、このイベントを「Nullableな値」として処理するため、
// 型の昇格（Type Promotion）には細心の注意が必要となる。
void processStream(Stream stream) {
stream.listen((int? value) {
// コンパイラはここで value が int であることを保証できない。
// そのため、明示的なチェックが必要となる。
if (value != null) {
// ここで value は int に昇格（Promotion）される。
// VMは最適化パスにおいて、この branch を頻出パスとして推論する。
print(value + 1);
}
});
}

`Stream?` の場合：ガード節の強制

一方、`Stream?` は「パイプラインが存在しない」という状態を許容する。これは非同期処理において非常に危険な設計だ。多くの場合、これは「ストリームの初期化失敗」を意味する。

void unsafeAccess(Stream? stream) {
// コンパイルエラー:
// “The method ‘listen’ can’t be unconditionally invoked because the receiver can be ‘null’.”
// stream.listen((e) => print(e));

// 安全なアクセスには、ガード節が必要となる。
// これはイベントループにイベントが届く前に、パイプラインの生存を確認するステップを挟む。
stream?.listen((event) => print(event));
}

—

3. シニアエンジニアが意識すべき「防壁」の設計

大規模システムにおいて、`Stream` の型定義を誤ると、バグの温床となるだけでなく、デバッグ不可能なNull例外をランタイムに引き起こす可能性がある。

1. データの欠損を意図的に扱う場合

「値がないこと」が正常なビジネスロジックである場合、`Stream` を使用する。ただし、ストリームの消費側（Consumer）での `null` チェックを強制するため、`requireData` や `whereNotNull()` を活用して型を早期に絞り込むべきだ。

// 効率的な null フィルタリング
final Stream nonNullStream = nullableStream.whereType();
// whereType は内部で型ガードを行い、null を透過的に排除する。
// コンパイラはこれを最適化し、null 判定の分岐を最小化する。

2. ストリームのライフサイクルを制御する場合

`Stream?` を使わざるを得ない場合、それは「未初期化」の状態を意味する。この場合、`late` キーワードや `Nullable` を単に使うのではなく、`BehaviorSubject` (RxDart) のような状態保持型のストリームを使い、Nullを流さない設計を検討すべきだ。

—

最後に：ランタイムエンジニアからの警告

DartのNull安全は、開発者の「怠慢」を許さない冷徹な仕組みだ。
`Stream` を定義したなら、それは「Nullを流す準備」をせよということ。
`Stream?` を定義したなら、それは「Nullである可能性を考慮したガード節」を実装せよということ。

この2つを混同しているコードベースは、いずれ `NoSuchMethodError` の迷宮に迷い込む。
コンパイラが警告を出しているのは、あなたが書いたコードの論理的な「穴」を指摘しているに過ぎない。その穴を埋めることは、パフォーマンスを最適化することと同義である。

型定義を厳密にすることは、VMが実行時に行う「型チェック」のコストを削減することに繋がる。正しい型定義こそが、最高のランタイムパフォーマンスを生む。

これを忘れないでほしい。