【実務・中級編】Nullable型の徹底活用：PHPのis_nullチェックをHackのOptionパターンへ昇華させる – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Nullを「撲滅」せよ：HHVMの型システムを最大化するOptionパターンの真髄

PHPからHackへ移行する際、多くのエンジニアが犯す最大の過ちは、「PHPの書き方をそのままHackの型システムに流し込もうとすること」だ。

`if ($var !== null)` を羅列するコードは、単なるボイラープレートではない。それは、君たちのコードベースに「型安全性の穴」をドリルで開けているのと同じだ。Hackの静的型チェッカー（HHVM Typechecker）を飼いならし、NullableをOptionパターンへと昇華させることで、実行時の予期せぬ `null` 参照によるクラッシュを根絶する設計論を叩き込む。

—

1. なぜ `if` 文によるチェックは「敗北」なのか

PHPのレガシーなコードでは、変数の状態を `if` で分岐させるのが常識だった。だが、Hackにおいてはこれは非効率であり、何より型推論の恩恵を自ら放棄している。

// [Bad] レガシーなPHP的発想
function process(?User $user): void {
if ($user !== null) {
// ここで型が絞り込まれるが、コードがネストし、
// 複雑なロジックでは推論が追いつかなくなるリスクがある
echo $user->getName();
}
}

このコードの敗北点は、「関数の契約」が明確でないことだ。`process` 関数は `null` を受け取ることを許容しており、呼び出し側は常にそのリスクを背負い続けなければならない。

—

2. Optionパターンへの昇華：`?->` 演算子を超えて

Hackには強力な `HSL (Hack Standard Library)` がある。我々が提供しているのは単なるユーティリティではない。型システムと対話するためのインターフェースだ。

もっともエレガントな手法は、Nullableを「値が存在するかどうかのコンテナ」として扱い、メソッドチェーンで解決することだ。

実践：`Option` 的なアプローチによる安全なデータ抽出

use namespace HH\Lib\C;

final class UserFetcher {
/

呼び出し元に「値が存在しない可能性」を明示的に強制する

/
public function getDisplayName(?User $user): string {
// 1. null安全演算子 (?->) を活用
// 2. ?? (null合体演算子) でデフォルト値を注入
// 3. これによりif文のネストを完全排除
return $user?->getName() ?? ‘Guest’;
}
}

ここで重要なのは、`??` を活用して常に「非Nullableな値」へ確定させるという設計指針だ。ビジネスロジックの深層部で `?` を引きずるのは、設計の怠慢である。

—

3. HSLを活用した「型変換」の極致

非同期APIからのレスポンスを処理する場合、`vec` や `dict` に格納されたデータが `null` である可能性をどう排除するか。ここで `HH\Lib\Vec\filter_nulls` を活用する。

use namespace HH\Lib\Vec;

function processUsers(vec $users): void {
// nullをフィルタリングし、型を vec に昇華させる
$activeUsers = Vec\filter_nulls($users);

// これ以降、$activeUsers は確実に null を含まない
foreach ($activeUsers as $user) {
$this->syncToExternalService($user->id);
}
}

このアプローチの利点は、「ループの中で `if ($user === null) continue;` を書く必要がない」という点だ。型チェッカーは `filter_nulls` の戻り値を `vec` と認識し、君たちの書くロジックから `null` 可能性を物理的に消去する。

—

4. チーフアーキテクトからの忠告：パフォーマンスと保守性

HHVMのJITコンパイラは非常に優秀だが、型チェックのコストを軽視してはいけない。

1. 型絞り込み（Type Refinement）の多用: 複雑な条件分岐で型を絞り込むよりも、関数の入口で `invariant` を使って型を確定させる方が、HHVMの最適化パスに乗りやすい。
2. Nullableの連鎖: `?->` を多用しすぎると、深いネストした構造のデバッグが困難になる。もし `null` が多発するなら、それはモデルの設計ミスだ。「データが存在しないこと」自体を `Option` のようなラップされた型で表現し、値を抽出するタイミングを制御せよ。
3. HSLの活用: 自前で複雑な型ガード関数を書くのはやめろ。HSLの関数はC++レベルで最適化されており、自前コードよりも圧倒的に速い。

—

結論：コードは「書くもの」ではなく「定義するもの」

君たちが書くHackのコードは、単なる命令の羅列ではない。型という名の「境界線」を設計する作業だ。

`if` 文で逃げるのは簡単だ。だが、それは君たちのコードベースの価値を毀損させる。Nullableを適切に処理し、HSLを通じてデータフローを型安全に保つこと。それこそが、HHVMという強固なプラットフォームの上で、バグ知らずのプロダクションコードを走らせるための唯一の道だ。

次のPRからは、`if` 文を消し去り、型推論の力を信じてコードを「定義」することから始めてみてほしい。それができるようになった時、君たちは本当の意味でHackを掌握していると言えるだろう。