Hackの型エラーは「敵」ではない。型チェッカーと対話し、堅牢なコードを書き上げるための極意
Hackの型チェッカー（`hh_client`）が吐き出す真っ赤なエラーメッセージ。これを見て「またか」と溜息をついているなら、あなたはまだHackの真髄に触れていない。
Hackの型チェッカーは、単なる文法チェッカーではない。それは、君が書いたコードが「HHVMのJITコンパイラが最高効率で実行できる状態か」を静的に検証し、メモリレイアウトの不整合や実行時の型混乱（Type Confusion）を未然に防ぐための「最強の守護神」だ。
今日は、型エラーを単なる修正対象ではなく、システム設計を洗練させるためのフィードバックループに変えるための視点を伝授する。
—
1. 型エラーメッセージの「解剖学」
型エラーメッセージを読み解く際、多くのエンジニアは「何が間違っているか」だけを見る。だが、真のアーキテクトは「どこから推論が崩れたのか」の経路を追う。
File “user.php”, line 12, characters 10-15:
Invalid return type (Typing[4110])
File “user.php”, line 8, characters 20-22:
Expected int
File “user.php”, line 10, characters 5-15:
But got ?string
この構造を分解しよう：
1. [4110] (Typing Error): 型の一致失敗。Hackのコアエンジンが「この型は実行時にメモリ上のサイズが確定できない（あるいは想定と違う）」と判断した合図だ。
2. Expected: チェッカーが「このメモリ領域にはこの型があるべき」と定めた期待値。
3. But got: 実際に渡された型。
教訓: エラーが起きている行（line 12）は単なる「結果」に過ぎない。真の問題は「なぜそこまで `?string` が侵入したのか」というデータの流れ（フロー）にある。
—
2. 堅牢な設計：Option型の「強制ハンドリング」
Web API連携で最も多いバグは、nullチェックの漏れだ。Hackでは `?T` (Nullable) を扱う際、安易なキャストは厳禁だ。`if ($val is nonnull)` を使ったRefinement（型絞り込み）を徹底することで、コンパイラに「ここからは確実にこの型である」という安全な制約を教える必要がある。
推奨される実装パターン
非同期API連携で、型安全を担保しつつ保守性を維持する例だ。
namespace App\Service;
use type HH\Lib\C;
class UserFetcher {
/
- 型の曖昧さを排除し、Resultパターンに近い設計を行う
/
public async function getUsernameAsync(int $userId): Awaitable
$data = await $this->fetchFromExternalApi($userId);
// 1. 型絞り込み（Type Refinement）
// 実行時に型を確認し、型チェッカーに「このスコープ内ではnonnullである」と保証させる
if ($data is null) {
throw new \Exception(“User not found”);
}
// ここでは $data は string として認識される
return $data;
}
private async function fetchFromExternalApi(int $id): Awaitable {
// 外部APIからのレスポンスは常にNullableと仮定する
return “Hack_Master”;
}
}
—
3. なぜ `mixed` を避けるべきなのか
初心者が犯す最大のミスは、エラーを消すために `mixed` を多用することだ。
`mixed` は、HHVMにとって「型推論の放棄」を意味する。型情報が消えるということは、JITコンパイラが最適化を諦め、実行時に高コストな型チェックを挿入せざるを得なくなるということだ。
- パフォーマンスの観点: `mixed` が増えると、型ガードのための命令数が増え、CPUのパイプライン効率が劇的に低下する。
- 保守性の観点: 数ヶ月後の君が、その変数の中身を当てるのは不可能だ。
解決策: 複雑な構造体には必ず `shape` を定義せよ。
// ダメな例：配列で適当に返す
// function getUser(): array
// 美しい例：shapeで厳格に定義する
type UserProfile = shape(
‘id’ => int,
‘username’ => string,
‘email’ => string,
);
function getUser(): UserProfile {
return shape(‘id’ => 1, ‘username’ => ‘dev’, ‘email’ => ‘dev@example.com’);
}
—
4. チーフアーキテクトからの提言
Hackでコードを書くとき、常に自問自答してほしい。
「このコードは、型チェッカーを『納得』させているか？」
型エラーを抑制剤（`HH_FIXME`など）で誤魔化すのは、傷口に絆創膏を貼るのと同じだ。エラーが発生したら、それは「君の設計に論理的な穴がある」という型チェッカーからの警告である。その穴を埋めることで、コードは驚くほどシンプルになり、実行時のメモリ消費量は減り、システムの安定性は飛躍的に向上する。
Hackは、君の思考をより「論理的」かつ「厳格」に研ぎ澄ますためのツールだ。型チェッカーと戦うのではなく、対話し、その制約を武器にせよ。
君が書くその一行が、次のHackエコシステムのスタンダードになることを期待している。