Dart 3の `if-case` で実現する「型変換の革命」：Null安全を極めるための思考法
Dartのコードベースを見ていると、いまだに `if (value != null)` を連打し、その中で `value!` という強制アンラップ（Bang演算子）を使っているコードに出会うことがあります。
はっきり言おう。その書き方は、Dart 3の世界では「負債」だ。
我々コアチームがパターンマッチングを言語仕様に組み込んだのは、単なるシンタックスシュガーの追加ではない。コンパイラのフロー解析において、「型チェックとデータ抽出を不可分なアトミック操作にする」ことで、ランタイムの安全性とコードの可読性を一段上のレベルへ引き上げるためだ。
今日は、Null許容型（Nullable）を非Null型（Non-nullable）へと安全に変換し、堅牢なプロダクションコードを書くための「if-case」活用術を伝授する。
—
なぜ従来の `if (x != null)` は「二流」なのか
従来のガード節による記述を見てほしい。
// 悪い例：典型的なレガシーパターン
void process(String? input) {
if (input != null) {
// 冗長なガード。ここから先、コンパイラは「inputがnullでないこと」を推論するが、
// 構造体や複雑なデータクラスでは、この推論が途切れやすい。
print(input.trim());
}
}
このアプローチの問題点は、「型チェック」と「値の利用」が分断されている点にある。もし `input` がクラスのフィールド（インスタンス変数）であれば、他のIsolateや非同期処理、あるいは同期的なセッターによって値が書き換えられるリスクをコンパイラは完全に排除しきれない。そのため、毎回 `!` を強いることになり、コードのノイズが増える。
—
`if-case` がもたらす「型推論の確信」
Dart 3の `if-case` を使えば、チェックと同時に「ローカルな変数への昇格」を完結できる。
// 洗練された例：if-caseによるパターンマッチング
void process(String? input) {
if (input case final value?) {
// ここで value は String 型として完全に昇格（Promotion）される。
// また、final であるため、このスコープ内で値が書き換わるリスクもない。
print(value.trim());
}
}
なぜこれが強力なのか？
- アトミックな評価: `case final value?` は「値が存在し、かつそれが非Nullである」ことを一撃で評価する。
- スコープの最小化: 変換後の変数 `value` は、ifのブロック内でのみ生存する。スコープ外への汚染を防げる。
- コンパイラの最適化: Dart VMは、このパターンマッチングが実行された後のパスにおいて、値の型が固定されていることを確信できるため、最適化（AOTコンパイル時）の余地が広がる。
—
実践：APIレスポンスの型安全な分解
実務で最も頻発する「非同期API連携」のシーンで、このパターンを応用してみよう。JSONデコード後のデータ構造を扱う際、これほど頼りになる構文はない。
typedef ApiResponse = Map
void handleResponse(ApiResponse response) {
// マッピングされたJSONから、特定のパターンのみを安全に抽出する
if (response case {‘data’: final String body, ‘status’: 200}) {
print(‘成功: ${body.toUpperCase()}’);
} else if (response case {‘error’: final String message}) {
print(‘エラー: $message’);
} else {
print(‘予期せぬレスポンス形式’);
}
}
このコードの美しさは、「データが期待する形状（Shape）をしているか」を評価する過程で、同時に必要な値を取り出している点だ。`if-case` は条件分岐と変数の初期化を統合する強力な武器となる。
—
パフォーマンスと注意点：伝説のアーキテクトからの助言
「パターンマッチングを使うと実行速度が落ちるのではないか？」と心配する声があるが、それは杞憂だ。
Dart VMにおいて、`if-case` は通常の `if` 文よりも高速、あるいは同等に動作するようコンパイラ側で最適化されている。なぜなら、パターンマッチングの論理はコンパイル時に 「決定的な分岐ツリー」 として展開されるからだ。
ただし、一点だけ注意してほしい。
「深いネスト」は厳禁だ。
パターンマッチングは強力だが、複雑なJSONを一度に全てマッチさせようとすると、コードの可読性が著しく低下する。
- 良い設計: レスポンスのトップレベルで `if-case` を使用し、構造を分解する。
- 悪い設計: 3階層以上のネストを一つの `if-case` に詰め込む。
もし構造が深い場合は、`extension` を切って `fromMap` などのコンストラクタでモデル化し、その後に `if-case` を使うのが、Dartの流儀であり、保守性の高いプロダクションコードの鉄則だ。
—
まとめ：明日から導入すべきアクション
1. `!` をコードから追放する: `value!` と書きたくなったら、それは `if-case` を使うべきサインだ。
2. `case final …?` を標準にする: Nullable型を扱うときは、必ずこのパターンを第一候補にする。
3. 型昇格を信頼する: Dartの型推論システムは、君たちが思っている以上に賢い。適切にパターンマッチングを行えば、コンパイラは君の意図を完璧に理解する。
Dartは、ただの「書きやすい言語」ではない。正しく使えば、コンパイラと開発者が強固な合意を形成し、バグを未然に防ぐ「堅牢なエンジン」に変わる。
さあ、コードを開いて、その汚れた `null` チェックを `if-case` に書き換えよう。君たちのプロダクトに、真の型安全をもたらすために。