Dart 3 レコードとパターンマッチングの真実：なぜ「多重戻り値」はメモリに優しいのか
コードレビューをしていると、未だに複数の値を返すためにわざわざ使い捨ての `class` を定義したり、冗長な `Map
「Dart 3がある時代に、なぜそれをやっているのか？」
Dart 3で導入されたレコード型（Records）とパターンマッチング（Pattern Matching）は、単なるシンタックスシュガーではない。これらは、言語の型システムとコンパイラ（AOT/JIT）の最適化が密接に結びつき、ヒープアロケーションを極限まで削減しながら堅牢性を高めるための強力な武器だ。
今回は、Dartコアの内部構造とメモリ効率の観点から、レコード型を駆使したモダンな多重戻り値の設計論を叩き込む。
—
1. なぜ従来の多重戻り値は悪手だったのか？
Dart 2時代、非同期APIやコンポーネントの状態管理において、1つの関数から複数の関連する値（例：データとエラー状態、あるいはページネーションのメタデータ）を返したい場合、以下のいずれかを選択せよと言われていた。
1. 専用のDTOクラス/ラッパークラスを作る
- 弊害: ボイラープレート（冗長なコード）が増え、名前空間が汚染される。
2. `Map
- 弊害: 型安全性が完全に消失し、タイポによる実行時クラッシュの温床になる。
3. リストや配列で返す
- 弊害: `result[0]`, `result[1]` のインデックスが何を指すのか意味不明になり、保守性が崩壊する。
これらはすべて、パフォーマンス的またはメンテナンス的な「負債」を抱えていた。クラスのインスタンス化はヒープ領域へのメモリ割り当て（Allocation）を伴い、ガベージコレクタ（GC）に負荷をかける。
—
2. レコード型はメモリ上でどう扱われるか？
Dartのレコードは、構造的型付け（Structural Typing）を持つ、匿名かつ軽量な複合データ型だ。
コンパイラとDart VMの視点から見ると、レコードは生成時に可能な限りスタック上（またはレジスタ上）で最適化されるように設計されている。クラスのようにインスタンスのヘッダ情報や仮想メソッドテーブル（vtable）を持つ必要がないため、ヒープメモリを消費しないケースが多い。
パターン分解（Destructuring）時のコピーの有無
結論から言えば、Dartのパターン分解時に無駄なメモリコピーは発生しない。
コンパイル時に、レコード内の各フィールドはそれぞれローカル変数（あるいはレジスタ）に直接バインドされる。C++の `std::tie` や Rust の分解代入に近い効率性を持っており、実行時のオーバーヘッドはほぼゼロだ。
—
3. 【実践】堅牢性と美しさを両立するプロダクションコード
フロントエンドの状態管理や非同期API連携において、非同期処理の結果（データ、ローディング状態、エラー）を美しく、かつバグが起きない形で扱うコード例を示す。
以下のコードは、そのままプロダクションのコードベースに組み込める設計だ。
import ‘dart:async’;
// =================================================================hausen
// ドメインモデルとカスタム例外
// =====================================================================
class UserProfile {
final String id;
final String name;
const UserProfile({required this.id, required this.name});
}
sealed class ApiError implements Exception {
const ApiError();
}
class NetworkError extends ApiError { const NetworkError(); }
class UnauthorizedError extends ApiError { const UnauthorizedError(); }
// =====================================================================
// リポジトリ層：レコード型による多重戻り値の提供
// =====================================================================
class UserRepository {
/// ユーザーデータと、後続リクエスト用のページネーション情報を同時に返す
/// 戻り値: (UserProfile? data, ApiError? error, bool hasNextPage)
Future<(UserProfile?, ApiError?, bool)> fetchUserWithPagination(String userId) async {
// ネットワーク遅延のシミュレーション
await Future.delayed(const Duration(milliseconds: 300));
// 異常系シミュレーション
if (userId == ‘401’) {
return (null, const UnauthorizedError(), false);
}
if (userId.isEmpty) {
return (null, const NetworkError(), false);
}
// 正常系
final profile = UserProfile(id: userId, name: ‘Dart Expert #${userId}’);
return (profile, null, true);
}
}
// =====================================================================
// プレゼンテーション / UI層でのパターンマッチング活用
// =====================================================================
void main() async {
final repo = UserRepository();
// テストケース1: 正常系
await handleApiCall(repo, ‘007’);
// テストケース2: 認証エラー系
await handleApiCall(repo, ‘401’);
}
Future
print(‘— Fetching for ID: $targetId —‘);
// レコードの多重戻り値を直接パターン分解（Destructuring）
// 冗長なラッパークラスは一切存在しない
final (profile, error, hasNext) = await repo.fetchUserWithPagination(targetId);
// Dart 3の switch Expressions とパターンマッチングによる網羅的（Exhaustive）な安全処理
// コンパイラがすべての状態（errorの種類）を網羅しているかを静的に検証する
var displayMessage = switch ((profile, error)) {
// 1. エラーが存在する場合
(null, final ApiError err) => switch (err) {
NetworkError() => ‘ネットワーク接続を確認してください。’,
UnauthorizedError() => ‘セッションが切れました。再ログインが必要です。’,
},
// 2. データが正常に取得できた場合
(final UserProfile p, null) => ‘ようこそ、${p.name}さん！ (追加ページ: ${hasNext ? “あり” : “なし”})’,
// 3. 予期せぬ状態（型システムにより理論上到達しないが、安全性の担保）
_ => ‘予期せぬシステムエラーが発生しました。’,
};
print(displayMessage);
}
—
4. チーフアーキテクトからの設計上の警鐘
このコードとアーキテクチャを採用するにあたり、以下の原則をチームに徹底してほしい。
1. レコードの要素数は「3つ」を上限とせよ
`(A, B, C, D, E)` のようにフィールドが増加したレコードは、もはや意味の判別がつかなくなり、ナンセンスな「名前なしタプル」と化す。要素が4つ以上になる、あるいはドメインとして重要な意味を持つ場合は、躊躇わずに専用の `class` または `base record` を定義すべきだ。レコードが真価を発揮するのは、「局所的な多重戻り値」の文脈に限定した場合である。
2. 名前付きフィールド（Named Fields）を適切に使え
今回の例では位置ベースのレコード `(UserProfile?, ApiError?, bool)` を使ったが、呼び出し側で順序の勘違いが起きそうな複雑なデータ構造の場合は、`(UserProfile? data, ApiError? error, bool hasNext)` のように名前付きフィールドを活用せよ。IDEの補完が効き、保守性が劇的に向上する。
結び
Dart 3のレコードとパターンマッチングは、開発者の認知負荷を下げると同時に、コンパイラに優しい効率的なコードを生み出すための現代の必須教養だ。
「とりあえずクラスを作っておこう」という思考停止を捨て、メモリと型の仕組みを理解した上でコードベースを研ぎ澄ましてほしい。君たちの書くコードは、もっと速く、美しくなるはずだ。