こんにちは！Hack言語の世界へようこそ。フルスタックエンジニアの先輩として、今日から君をこの美しく強力な言語のさらに深い領域へと案内するね。
今回は、Hackの静的型システムの真骨頂とも言える「Strict Mode（厳格モード）」におけるUnion Types（直和型）の網羅的チェックとパターンマッチングについて、徹底的に解説していくよ。
「他の言語から来たけれど、型の安全性を高めすぎてコードが複雑になってしまう……」
「Union Typesを扱いたいのに、条件分岐で型エラーに悩まされる……」
そんな壁にぶつかっていませんか？
大丈夫、ここをクリアすれば、君はもうHackの型チェッカーを完全に手なずけたも同然です。さあ、一緒に本質を紐解いていきましょう！
—
1. HackのStrict ModeとUnion Typesの基本概念
まず、Hackの心臓部であるType Checker（型チェッカー）の挙動を軽くおさらいしておこう。Hackはすべてのファイルを基本原則としてStrict Modeで書くことを推奨（というか現代のHackではそれがデフォルト）しています。これは「推測に頼らず、すべての型を明示せよ」という思想の表れです。
そんなStrict Modeの中で、複数の異なる型を内包するデータ構造を扱うときに登場するのが Union Types（直和型） ですよね。
イメージとしては、こんな感じです。
[ Union Type: データの可能性 ]
├── 整数 (int)かもしれない
├── 文字列 (string)かもしれない
└── カスタムオブジェクトかもしれない
「どれの可能性があるか」が分かっているのだから、コードを書く側も「すべての可能性に対してどう処理するか」をコンパイラに示さなければなりません。ここで活きてくるのが、Hackの型チェッカーによる網羅性チェック（Exhaustiveness Checking）です。
—
2. 具体的なコードで学ぶ：安全なパターンマッチング
百聞は一見にしかず。実際のコードを見てみましょう。
例えば、APIから返ってくるレスポンスの状態（成功・エラー・ローディング中）をUnion Typeとして表現し、それを処理するケースを考えてみます。
// strict
<
namespace MyApp;
// 各状態を表現するデータ構造
type Success = shape(‘status’ => string, ‘data’ => string);
type Failure = shape(‘status’ => string, ‘error_code’ => int);
type Loading = shape(‘status’ => string);
// これらが複合したUnion Type
type ApiResponse = Success | Failure | Loading;
function handle_response(ApiResponse $response): string {
// pattern matching using switch or match
// statusキーの値に基づいて型を絞り込む（Refinement）
switch ($response[‘status’]) {
case ‘success’:
// ここでは $response は Success 型として安全に扱える
return “Success: ” . $response[‘data’];
case ‘failure’:
// ここでは Failure 型に絞り込まれる
return “Error Code: ” . (string)$response[‘error_code’];
case ‘loading’:
// ここでは Loading 型に絞り込まれる
return “Now Loading…”;
// デフォルトケースを書かなくても、型チェッカーが網羅性を検証してくれる！
}
}
コードのポイント
1. 型の絞り込み（Type Refinement）: Hackの型チェッカーは非常に賢く、`switch` 文の条件分岐の中でどの型に該当するかを静的に追跡し、ブロック内での型を自動的に絞り込んでくれます。
2. 網羅性の保証: もし将来、新しい状態 `Timeout` が追加されたとき、この `switch` 文に新しい `case` を書き忘れると、Hackの型チェッカーは容赦なくエラーを吐き出します。「処理の漏れ」を人間ではなくコンパイラが完全に防いでくれるのです。これが最高に心地いいところですね。
—
3. 陥りやすい文法エラーと、その対策
初心者の開発者がこの領域でよくハマる罠がいくつかあります。代表的なものを挙げておくので、事前に頭に入れておきましょう。
罠1: 「網羅しきれていない」というコンパイルエラー
もし、先のコードから `case ‘loading’:` を消してしまったとします。すると、型チェッカーはこう怒ってきます。
> TypeChecker Error: Non-exhaustive switch statement…
「おいおい、`Loading` 型の可能性が処理されてないぞ！」と型チェッカーが教えてくれているわけです。
対策: Union Typeを構成するすべての型に対する分岐を必ず記述するか、どうしても網羅したくない（あるいは将来の拡張に備えたい）場合は、適切なデフォルト処理を設計し直しましょう。
罠2: 絞り込みが効かない複雑な条件分岐
`switch` や `if` の条件式が複雑になりすぎると、型チェッカーが「今どの型に絞り込まれているか」を追跡できなくなることがあります。
// 良くない例：複雑すぎてチェッカーが迷子になることがある
if ($response[‘status’] === ‘success’ && $some_global_flag) {
// …
}
対策: なるべくシンプルなキー値の比較や、ハックが提供するパターンマッチング構文（`match` 式など）を活用し、型チェッカーが推論しやすい構造を心がけましょう。
—
4. HHVMのアーキテクチャの裏側：なぜこれが高速なのか？
ここで少し、裏側で動いている HHVM（HipHop Virtual Machine） の話もしておきましょう。
「こんなに厳格に型をチェックして、実行時ペナルティはないの？」と心配になるかもしれませんが、答えは「ノー、むしろ爆速になる」です。
HHVMは、Hackの静的型情報を信頼し、JIT（Just-In-Time）コンパイラを通じて、最適化されたマシン語を直接生成します。PHPのように「実行するまでデータの型が分からない」というオーバーヘッドがないため、Union Typesを使った条件分岐であっても、内部的には非常に効率的なジャンプテーブルやインラインキャッシュとしてコンパイルされます。
型チェッカーがコンパイル時に安全性を担保してくれるおかげで、HHVMは実行時に無駄な型チェック（is_int だの instanceof だの）を行う必要がなくなる。これが、Hackが圧倒的なパフォーマンスを誇る理由の一つです。
—
まとめ
今回は、Strict ModeにおけるUnion Typesの網羅的チェックとパターンマッチングについて解説しました。
- Union Types を使うことで、データの取りうる状態を美しく表現できる。
- 型チェッカーの網羅性チェックにより、条件分岐の書き忘れをコンパイル時に完全に防げる。
- HHVMのJIT最適化により、安全性とパフォーマンスが最高レベルで両立する。
ここをクリアできれば、君はもうHackのコードから「予期せぬ型エラー（TypeError）」の恐怖をほぼ排除できるようになります。ぜひ実際のプロジェクトで試してみてくださいね。
それでは、次回の極限の知見でお会いしましょう！バッチリマスターしていってください！