Dart 3 レコードとパターンマッチングの深層：メモリ効率、スタック割り当て、そしてコンパイラの最適化戦略
Dart 3におけるレコード（Records）とパターンマッチング（Pattern Matching）の導入は、単なるシンタックスシュガーの追加ではない。これは、言語の表現力を飛躍的に高めると同時に、Dart VMおよびAOTコンパイラ（dart2native）のコード生成パイプラインに根本的な変革をもたらした構造的進化である。
本稿では、一般の入門書が語ることのない、スタックフレーム上でのメモリレイアウト、アロケーションの回避メカニズム、そしてパターン分解時に発生するアセンブリレベルの挙動に至るまで、Dartランタイムの深層を解剖する。
—
1. レコードのメモリ物理学：なぜ「クラス」ではないのか
従来のDartにおいて、複数の値を関数から返すためには、カスタムクラス、`List`、あるいは`Map`を生成せよという選択肢しかなかった。これらはすべてヒープ（Heap）上のアロケーションを伴う。
// 従来のアンチパターン：ヒープを汚染するクラス生成
class Point {
final double x;
final double y;
Point(this.x, this.y);
}
Point calculate() => Point(10.0, 20.0);
このコードが実行される時、Dart VMはヒープ上に`Point`オブジェクトのためのメモリ領域を確保し、GC（ガベージコレクション）の監視対象とする。ミリ秒単位の応答性が求められるフレームワーク層や、ホットパス（Hot Path）において、この小さなアロケーションの蓄積がGCプレッシャーを生み出し、フレームドロップの主原因となる。
スタック割り当て（Stack Allocation）とインライン化
これに対し、Dart 3のレコードは名前のない、構造的に型付けされた不変の複合データ型である。
// Dart 3 レコード：スタック上で完結する多重戻り値
(double, double) calculateOptimized() => (10.0, 20.0);
コンパイラ（AOT / JIT）の視点において、このレコードはヒープ上のオブジェクトとしてインスタンス化されない。多くの場合、関数呼び出しのABI（Application Binary Interface）に従い、CPUのレジスタ（x86-64であれば`XMM`レジスタなど）に直接配置されるか、呼び出し元のスタックフレーム上の連続したメモリスロットにインライン展開される。
GCの追跡コストは完全にゼロであり、メモリの局所性（Locality of Reference）が極限まで高まる。キャッシュミスの確率が劇的に低下し、CPUのパイプラインを淀みなく流れるのだ。
—
2. パターン分解（Pattern Decomposition）の裏側：コピーは発生するか？
開発者が最も懸念すべき点の一つは、「パターンマッチングを用いた分解時に、値のコピーや不要なテンポラリ変数の生成によるオーバーヘッドが発生するのではないか」という点だろう。
以下のコードを検証する。
void processResponse((int status, String body, bool isSecure) response) {
// パターン分解
var (status, body, isSecure) = response;
if (status == 200 && isSecure) {
print(‘Secure Payload: $body’);
}
}
コンパイラの静的解析とレジスタ割当て
Dartコンパイラは、このパターン分解を構文木（AST）レベルから中間表現（IL: Intermediate Language）に変換する際、「値の再配置（Move）」として処理する。
1. `response` レコードが保持するフィールド群（`int`, `Pointer
2. 分解代入 `var (status, body, isSecure) = response;` は、新たなメモリ領域への「ディープコピー」を引き起こさない。
3. コンパイラは、それぞれのフィールドに対応するスタックオフセット、あるいはレジスタのエイリアス（別名）を割り当てるだけである。
つまり、参照型のフィールド（今回の `String`）であれば、ポインタの値（アドレス）がそのまま渡されるだけであり、実データの複製コストは完全に排除されている。C++における `std::tie` や Rust の destructuring と同等の、ゼロコスト抽象化が担保されている。
—
3. 実践：高スループット・低レイテンシを実現する設計パターン
シニアエンジニアとして、この特性をプロダクションコードでどう活かすべきか。エラーハンドリングと多重戻り値の組み合わせを例に、極限まで洗練されたパターンを示す。
import ‘dart:async’;
/// ネットワークパケットの解析結果をゼロアロケーションで表現するレコード型定義
typedef PacketParseResult = (bool isValid, Map
PacketParseResult parseNetworkPacket(List
// 簡易的なバリデーション
if (rawData.isEmpty) {
return (false, null, ‘ERR_EMPTY_PACKET’);
}
if (rawData.length < 4) {
return (false, null, 'ERR_MALFORMED_HEADER');
}
// 成功時のペイロード構築（必要最小限のヒープ割り当て）
final payload = {
'magic': rawData[0],
'version': rawData[1],
'length': rawData.length,
};
return (true, payload, null);
}
void handlePacketStream(List
// パターンマッチングによる分岐の網羅性と効率的な変数束縛
switch (parseNetworkPacket(incomingData)) {
case (isValid: true, payload: final data?, errorCode: null):
// 成功パス：コンパイラはここで data が非nullであることを静的に保証している
_dispatchToWorker(data);
break;
case (isValid: false, payload: null, errorCode: final error?):
// 失敗パス：エラーコードに応じた防御的処置
_handleError(error);
break;
default:
// 予期せぬ状態（型システムとレコード構造により、ここには到達しないはずの不変条件）
throw StateError(‘Unreachable protocol state detected.’);
}
}
void _dispatchToWorker(Map
// ワークロード処理
}
void _handleError(String code) {
// エラー処理
}
このコードの優位性
1. 例外のスローを回避: 例外（Exceptions）はスタックトレースの生成やアンワインド処理により、パフォーマンス上の大きなペナルティとなる。レコードによるステータス返却は、ホットパスにおける例外スローを根絶する。
2. 網羅性チェック（Exhaustiveness Checking）: Dart 3のスイッチ表現および文におけるパターンマッチングは、コンパイル時にすべてのケースが処理されているかを検証する。将来的にエラーコードが増えた際、コンパイラが未処理のパターンを検出し、バグの混入を未然に防ぐ。
—
4. アーキテクトからの提言：Isolate間通信（SendPort）におけるレコードの罠
最後に、システムアーキテクチャの観点から極めて重要な注意点を述べておく。
ここまで「レコードはスタック上で最適化され、高速である」と説いてきたが、これを `SendPort.send()` を用いた Isolate 間通信 でそのまま送信しようとした場合、挙動が変わる点に注意しなければならない。
Isolate間を跨ぐデータ転送は、メッセージのシリアライズとコピー（あるいはトランスファー）を伴う。レコード自体は軽量な構造体であるが、異なるIsolateのメモリ空間へ渡す際には、内部のフィールドがパッキングされ、受信側で再構築される。
したがって、
- 同一Isolate内（メインスレッド内や同期処理のパイプライン）: レコードのスタック最適化とパターンマッチングを最大限に活用し、アロケーションをゼロにする。
- Isolate間通信: 従来のクラスやバイト配列（`TypedData`）の転送効率と比較し、シリアライズコストが見合うかプロファイリングを行う。
Dart 3のレコードとパターンマッチングは、言語の美しさとマシーン寄りのパフォーマンスを高次元で融合させた最高傑作の一つである。その内部構造（メモリレイアウト、スタック割り当て、ゼロコピーの分解）を完全に脳内トレースした上でコードを紡ぎ出すとき、あなたの書くDartアプリケーションは、ネイティブコードの極限領域へと到達する。