こんにちは！Hack言語の世界へようこそ。世界最高峰のHHVMとHackの内部構造を知り尽くした私が、今日あなたを「Hackの静的型システムを完全に手なずけるエンジニア」へと引き上げます。
他の言語、例えばPHPやJavaScriptからやってきた開発者が最初に直面する高い壁……それがHHVM型チェッカー（hhvm typechecker）からの冷徹なエラーメッセージです。
「なぜこのコードが動かないんだ！」「合っているはずなのに型エラーが出る！」
そんな風に頭を抱えた経験はありませんか？
大丈夫、安心してください。型チェッカーはあなたを困らせるために意地悪をしているわけではありません。実はあれ、「コードに潜むバグの芽を、実行する前に100%摘み取るための優しいコンパス」なんです。
今回は、複雑な型エラーのログから「型推論の矛盾」を瞬時に特定し、コードを美しく修正するためのデバッグスキルを一緒にマスターしていきましょう。ここをクリアすれば、Hackの基本はバッチリマスターできますよ！
—
1. Hackの「Strict Mode」と型チェッカーの基本思想
Hack言語を扱う上で、ファイルの先頭に書くこのお呪いを覚えていますか？
<
strict
これがStrict Mode（厳格モード）です。このモードでは、すべての変数、関数の引数、戻り値に明確な型が必要です。「なんとなく型推論に頼る」のではなく、プログラマが意図を完全にコードに刻み込む世界です。
HHVMの型チェッカーは、コードを実行する前にAST（抽象構文木）を解析し、ミリ秒単位で型の整合性を検証します。ここで重要なのは、「型チェッカーがエラーを吐いた瞬間、そのコードはプロダクション環境に出してはならないバグを内包している」ということです。
—
2. よくある「型推論の失敗」とエラーメッセージの解読
では、実際の開発現場でよく遭遇する「型推論の失敗」を例に見ていきましょう。
陥りがちな罠：Nullable（null許容型）の不適切な扱い
次のようなコードを書いたとします。ユーザーIDからユーザー名を取得する関数です。
<
strict
class User {
public function __construct(public string $name) {}
}
function find_user_by_id(int $id): ?User {
// ダミー実装：奇数IDならUserを返し、偶数ならnullを返すとする
if ($id % 2 === 0) {
return null;
}
return new User(“Alice”);
}
function print_user_name(int $id): void {
$user = find_user_by_id($id);
// ここでうっかり、nullチェックをせずにプロパティにアクセスしてしまう
Shapes::idx(…, …); // いや、普通にこう書いちゃったとする
echo “User name is: ” . $user->name;
}
このコードをHHVM型チェッカーにかけたとします。すると、以下のようなエラーが返ってきます。
Typing[4062]: Could not find member ‘name’ in an object of type ?User (Incompatible with null)
エラーメッセージの読み解き方
- `Typing[4062]`: これはHackの型エラーコードです。メンバーアクセスの失敗を示しています。
- `Could not find member ‘name’ in an object of type ?User`: 「`?User` 型のオブジェクトから `name` メンバーが見つかりませんでした」と言っています。
- `(Incompatible with null)`: 「なぜなら、その型は `null` を含む可能性があるからです」という親切な補足です。
なぜこのエラーが起きるのか？
`find_user_by_id` の戻り値は `?User`（Nullable User）です。つまり、この変数は `User` インスタンスかもしれないし、`null` かもしれないのです。
型チェッカーは、「もし `$user` が `null` だった場合、存在しないプロパティにアクセスして致命的なクラッシュ（Null Pointer Exception）が起きる危険性がある！」と見抜いて、ここでストップをかけているのです。
—
3. 型チェッカーを味方につける：スマートな解決策
このエラーを解消するにはどうすればいいでしょうか？ 答えは簡単です。型チェッカーに「ここでnullじゃないことを保証するよ」と教えてあげるだけです。
<
strict
class User {
public function __construct(public string $name) {}
}
function find_user_by_id(int $id): ?User {
if ($id % 2 === 0) {
return null;
}
return new User(“Alice”);
}
function print_user_name(int $id): void {
$user = find_user_by_id($id);
// 【解決策】明確なガード節（早期リターン）を入れる
if ($user is null) {
echo “User not found.”;
return;
}
// ここに到達した時点で、Hackの型チェッカーは
// 「この下のスコープでは $user は確実に User 型である」と自動的に型を絞り込みます（Flow Typing）
echo “User name is: ” . $user->name;
}
Flow Typing（フロータイピング）の魔力
ここがHackの真骨頂です。`if ($user is null)` というガードを抜けた瞬間、型チェッカーは賢くも `$user` の型を `?User` から `User` へと自動的に格上げ（Narrowing） します。
これにより、エラーは綺麗に消え去り、安全かつ高速なコードが完成します。
—
4. 複雑なジェネリクス（Generics）エラーに立ち向かう
もう少し高度な例を見てみましょう。コンテナやコレクションを扱う際に、ジェネリクスの型不一致でエラーが出ることがあります。
<
strict
class Repository
private vec
public function add(T $item): void {
$this->items[] = $item;
}
public function getFirst(): ?T {
return $this->items[0] ?? null;
}
}
function process_repository(Repository
// うっかり int を突い込もうとする
$repo->add(123);
}
これをチェッカーにかけたときのログです。
Typing[4110]: Invalid argument
Expected string
Got int
エラーの背景
- `Expected string`: リポジトリは `Repository
` として宣言されているため、内部の `T` はすべて `string` であるべきと推論されています。 - `Got int`: しかし、渡された値は `123`（int型）です。
型チェッカーは、「約束と違うデータが流し込まれようとしている！」と即座に検知してくれます。これにより、実行時エラー（Runtime Exception）の温床を完全にシャットアウトできるのです。
—
まとめ：エラーログは「最高の設計図」
Hackの型チェッカーから発せられるメッセージは、決してあなたを攻撃しているわけではありません。それは、「あなたのコードをより堅牢で、予測可能で、保守しやすいものにするための最高のアドバイス」です。
エラーメッセージに出くわしたら、以下のステップで冷静に脳内トレースしてみましょう。
1. エラーコードと該当箇所を確認する（どこで何が起きているか）
2. 期待されている型（Expected）と実際に渡されている型（Got）のギャップを見る
3. ガード節や型ナローイング（`is` 演算子など）を使って、型チェッカーに文脈を正しく伝える
このサイクルを回せるようになれば、あなたはもうHackの厳格な型システムを完全に手中に収めています。明日からのコーディングが、劇的に楽しく、自信に満ちたものになるはずですよ！
さあ、今日も美しいStrictなコードを書き続けましょう！