Nullableの呪縛を断て：HackのStrict ModeとMaybeモナド的型安全性の極限
HHVM（HipHop Virtual Machine）のコアエンジニアリングにおいて、最も排除すべき敵は何だと思うか？ メモリリークか？ JITのコンパイル遅延か？ いや、根源的な悪は `null`（NullPointerExceptionの父） という存在そのものだ。
PHPの遺産を引き継ぐHack言語において、`?T`（Nullable型）は甘美な毒である。存在しないかもしれない値を無防備に受け入れ、暗黙の型変換やガード節の漏れによって本番環境をクラッシュさせる。この悪習に終止符を打つのが、厳格モード（`<<____nocheck>>`の対極にある純粋な世界）における徹底的な`null`の排除と、関数型プログラミングにおける Maybeモナド（Option型） の概念のHack的実装である。
今回は、Hackの型チェッカー（hhvm）の挙動、バイトコードレベルの最適化、そしてメモリ効率を犠牲にせずに「存在しないかもしれない値」をどうハンドリングするか、その極限の知見を紐解こう。
—
1. なぜ `?T` は悪なのか：型チェッカーの盲点とランタイムコスト
まず、Hackにおける `?T` の実態をアーキテクチャの観点から暴く。
// 典型的なアンチパターン
function find_user(int $id): ?User {
$user = User::query($id);
return $user; // 見つからなければ null
}
function process_user(int $id): void {
$user = find_user($id);
// ガード節を忘れると、型チェッカーは strict mode でも
// 開発者が適切に扱っていると「誤認」するか、エラーを吐く。
// しかし、この「nullチェック地獄」がコードベースを腐敗させる。
if ($user !== null) {
// 処理
}
}
型チェッカーの視点では、`?T` は `T | null` の直和型（Union Type）として処理される。しかし、これは単なる論理的な型安全ではない。ランタイム（HHVM）の視点では、`null` を許容することは、ポインタが有効であるかどうかの分岐（Branch）をCPUパイプラインに強制することを意味する。
数百万リクエストを処理する高スループットなWebサービスにおいて、無数の分岐と `null` のハンドリングは、JITコンパイラが生成するネイティブコードの最適化を阻害する。さらに致命的なのは、「プログラマがnullチェックを書き忘れるリスク」がアーキテクチャ全体に常駐することだ。
—
2. HackにおけるMaybeモナド（`Option`型）の実装
HaskellやScalaにおける `Maybe` / `Option` モナドの思想をHackに持ち込む。
ここで目指すのは、「値が存在するかどうか」の責任を型システムに強制し、`null` をコードベースから完全に駆逐することだ。
以下のコードは、厳格な `strict` モード下で完全に安全に動作する `Option` 型のイディオムである。
namespace Architecture\Monad;
<
/
- Maybeモナド（Option型）の抽象定義
- 実行時オーバーヘッドを最小限にするため、構造化された不変データとして設計する。
/
interface IOption<+T> {
public function isSome(): bool;
public function isNone(): bool;
public function unwrap(): T;
public function unwrapOr(T $default): T;
// 関数型コンビネータ
public function map((function(T): U) $f): IOption;
public function flatMap((function(T): IOption) $f): IOption;
}
final class Some
public function __construct(private T $value) {}
public function isSome(): bool { return true; }
public function isNone(): bool { return false; }
public function unwrap(): T {
return $this->value;
}
public function unwrapOr(T $_default): T {
return $this->value;
}
public function map((function(T): U) $f): IOption {
return new Some($f($this->value));
}
public function flatMap((function(T): IOption) $f): IOption {
return $f($this->value);
}
}
final class None implements IOption
public function isSome(): bool { return false; }
public function isNone(): bool { return true; }
public function unwrap(): nothing {
throw new \RuntimeException(“Called unwrap() on a None value.”);
}
public function unwrapOr
return $default;
}
public function map((function(nothing): U) $_f): IOption {
return new None();
}
public function flatMap((function(nothing): IOption) $_f): IOption {
return new None();
}
}
この実装のキモ（Hackの型システムをハックする）
1. `nothing` 型の活用: `None` クラスは `IOption
2. 不変性（Immutability）: `private` なプロパティとコンストラクタによるカプセル化により、インスタンスの状態汚染を防ぎ、HHVMのビルトイン最適化（オブジェクトのスカラ化やプロパティのインライン展開）の恩恵を受けやすくしている。
—
3. 実践：データベース検索とビジネスロジックの構築
では、この `Option` 型を実際のドメインロジックでどう適用するか。
従来の `?User` を返すのではなく、必ず `IOption
namespace Architecture\Domain;
use namespace Architecture\Monosed;
use namespace HH\Lib\C;
class User {
public function __construct(
public int $id,
public string $email
) {}
}
class UserRepository {
// null を返すのではなく、IOption を返す
public static function findById(int $id): IOption
// 外部DBモック
$raw_data = self::query_database($id);
if ($raw_data === null) {
return new None();
}
return new Some(new User($raw_data[‘id’], $raw_data[‘email’]));
}
private static ?shape(‘id’ int, ‘email’ string) function query_database(int $id): ?shape(‘id’ int, ‘email’ string) {
// 実際にはここでDBアクセス
return $id === 1 ? shape(‘id’ => 1, ‘email’ => ‘architect@hhvm.internal’) : null;
}
}
そして、このリポジトリを利用するサービスクラスは、`null` チェックの迷宮から完全に解放される。
namespace Architecture\Service;
use namespace Architecture\Domain;
use namespace Architecture\Monad\{IOption, Some, None};
class NotificationService {
public function getFormattedEmailForUser(int $userId): string {
return Domain\UserRepository::findById($userId)
// Userオブジェクトが存在する場合のみ、emailを取り出して加工する
->map(($user) ==> $user->email)
// 万が一存在しない場合のフォールバックを宣言的に記述
->unwrapOr(‘guest@hhvm.internal’);
}
}
ここで `if ($user === null)` という汚染されたコードは1行も存在しない。すべての分岐は `Option` のコンビネータ（`map`, `flatMap`, `unwrapOr`）の内部にカプセル化され、型チェッカーがすべてのパスで型の整合性を完全に保証する。
—
4. HHVMのメモリ最適化とパフォーマンスの現実
「しかし、オブジェクト（`Some`, `None`）を毎回生成するのでは、GC（ガベージコレクション）のプレッシャーが増してパフォーマンスが落ちるのではないか？」
シニアエンジニアであれば当然そう疑うはずだ。この懸念に対するHHVMの内部挙動の回答を示そう。
1. ALLOCATION REUSE と JITの最適化:
HHVMのトレーシングJITは、短命なオブジェクト（Ephemeral Objects）に対して極めてアグレッシブな最適化を行う。特に `None` のような内部状態を持たないシングルトン的なオブジェクトは、静的にアロケーションを排除するか、レジスタ上に直接値の状態をマッピングする最適化（Scalar Replacement of Aggregates）の対象になり得る。
2. Boxing / Unboxing のコスト:
プリ型（`int`, `bool`）をモナドで包む際の値のボクシングが発生するが、Hackのジェネリクス（Reified Generics）は、PHPの動的なそれとは異なり、コンパイル時に型情報が維持されるため、HHVMのチル（Tear）最適化や型特化（Type Specialization）の恩恵を受けられる。
極限のパフォーマンスが求められるホットパス（Hot Path）では、`Option` クラスのインスタンス化すら避けてプリミティブなガードを使うべき場面はある。しかし、ビジネスロジック層、ドメインモデルの境界においては、「人間がバグを埋め込むコスト」は「CPUサイクル数微増のコスト」よりも圧倒的に高い。アーキテクトとして選ぶべきは常に前者だ。
—
5. 結び：コードベースの規律をコードで語れ
Hackの `strict` モードと、徹底された型設計の組み合わせは、もはや「PHPの親戚」としてのHackの枠組みを遠く超越している。
`null` をコードから追放せよ。
存在しないかもしれない値にはモナドの衣を着せよ。
型チェッカーをあなたの最高の防衛線として機能させよ。
コンパイлаがあなたの意図を完璧に理解し、ランタイムがそれを狂いなく実行する――その境地に到達したとき、あなたの書くHackコードは、ただのプログラムではなく、一つの美しいシステムアーキテクチャとなる。