`mixed`という名の「時限爆弾」を捨て去れ：Hack Strict Modeで到達する型安全の極致
Hackのコードベースで `mixed` を見かけるたび、私は「なぜこの開発者はコンパイラという強力な味方を敵に回すことを選んだのか」と自問する。
多くのエンジニアが「柔軟性」と「型安全性」をトレードオフだと誤解している。だが、HackにおけるStrict Modeの本質は、「不確実性をコードの外へ追い出し、型チェッカーを論理証明機として極限まで駆動させること」にある。
`mixed` は型システムにおける「白旗」だ。今日は、その白旗を掲げるのをやめ、実行時エラーをコンパイル時に焼き払うための設計哲学と実装パターンを伝授する。
—
1. なぜ `mixed` が悪なのか：型システムの「穴」を理解する
`mixed` は、HHVMの型チェッカー（HackC）に対して「この変数の正体は私にも分からない。何でもいいから通してくれ」と懇願する行為だ。
- 推論の遮断: `mixed` が混入した瞬間、型チェッカーはそこから先の推論を放棄する。連鎖的に型情報が失われ、バグの温床となる。
- ランタイムの不確実性: `mixed` を受け取った側は、必ず `is` チェックやキャストを強いられる。これは静的言語の利点を放棄し、動的言語の「実行時までバグが分からない」という地獄へ逆戻りすることを意味する。
我々の目的は「実行時の `if` や `is` を減らすこと」ではない。「型推論によって、そもそも実行時の不確実性を排除したコードを書くこと」にある。
—
2. 脱 `mixed`：静的型システムを最大化する設計パターン
実務において、外部APIのレスポンスやレガシーなデータ構造を扱う際に `mixed` に逃げたくなる瞬間があるだろう。しかし、そこには必ず「型定義（Shape）」による防壁を構築せよ。
ケーススタディ：非同期APIレスポンスの厳密な定義
JSONをデコードする際、適当な配列として扱うのは禁忌だ。`shape` と `typealias` を駆使し、データ構造をコードの境界で完全に制圧せよ。
<<__EntryPoint>>
async function run_robust_api_client(): Awaitable
// 外部からの入力を即座に型制約の檻に入れる
$response = await fetch_user_data();
// 構造が不確定な場合、即座に検証（Validation）し、型を確定させる
// ここで初めて ‘is’ を使う。これ以降は mixed は消滅する
if ($response is shape(‘id’ => int, ‘name’ => string)) {
process_user($response);
} else {
// 異常系はここで断ち切る
throw new InvalidArgumentException(“Invalid API structure”);
}
}
// 理想的なシグネチャ：推論を阻害せず、呼び出し元に安全を強制する
type UserProfile = shape(‘id’ => int, ‘name’ => string);
function process_user(UserProfile $user): void {
// ここにはもう ‘is’ は不要。型チェッカーが構造を完璧に保証している
echo “Processing user: ” . $user[‘name’];
}
—
3. 効率的な型絞り込み：`assert` と `is` の使い分け
Strict Modeにおいて、型チェッカーにヒントを与える `is` と、開発者の意図を強制する `invariant` を使い分けることは、アーキテクトとしての必須スキルだ。
現場で即効性のあるテクニック：`invariant` による事前条件の保証
use namespace HH\Lib\Str;
function update_user_email(string $email): void {
// 実行時エラーを早期に検出し、型チェッカーに ‘string’ であることを確約させる
invariant(Str\contains($email, ‘@’), “Email must be valid”);
// この行以降、型チェッカーは $email が ‘@’ を含むことを前提に最適化を行う
// 内部的には、HHVMのJITコンパイラが型情報を利用して効率的な機械語を生成する
}
—
4. パフォーマンスと型安全の相関
意外に思われるかもしれないが、`mixed` を排除することはパフォーマンスに直結する。
1. JITコンパイラの最適化: HHVMのJITは、型が確定しているコードに対しては強烈なインライン化とレジスタ割り当てを行う。`mixed` はこの最適化パスを分断し、動的なメソッドルックアップを誘発させる。
2. メモリレイアウト: Hackの `shape` や `record` を適切に使用すれば、データは最適化されたメモリレイアウトで保持される。`mixed` を多用した配列は、ハッシュマップとしてメモリを浪費する。
—
結論：コードは「対話」である
HackのStrict Modeは、コンパイラとの対話だ。「このデータはこうであるべきだ」と厳格に定義すれば、コンパイラは「その前提が崩れないよう、全ての経路で責任を持つ」と返してくれる。
`mixed` を使うのは簡単だ。だが、それは未来の自分やチームメンバーに「実行時エラーという爆弾」をプレゼントしているのと同じである。
Strict Modeで書くということは、自分たちの書くコードの「正当性」を数学的に証明し続ける行為だ。
今日からすべての `mixed` を消し去り、型定義の深淵へ潜れ。それが、エンジニアとしての品格であり、プロフェッショナルなアーキテクチャの第一歩である。
—
何か不明点があれば、型定義の `Shape` 構造を再確認することから始めよう。それでも解けないエラーは、設計そのものが歪んでいる証拠だ。