Hackを掌握する極限の知見：Function Typesにおける変性（Variance）の完全制覇
HHVM（HipHop Virtual Machine）のコアエンジニアリング、そして厳格なHackの静型システムの世界へようこそ。
日々のコードベースで `<<__Strict__>>` を宣言し、型チェッカーの厳密な恩恵を受けている君なら、単なるプリミティブ型やクラス階層における共変（Covariance）・反変（Contravariance）のルールは既に見飽きていることだろう。ジェネリクス（Generics）における `out` や `in` アノテーション、あるいは形状（Shapes）やタプルにおける型の方向性について迷うことはないはずだ。
だが、「関数型（Function Types）」そのものをファーストクラスの市民として扱い、高階関数のシグネチャに型制約を課した瞬間、多くのシニアエンジニアすらもコンパイルエラーの迷宮に迷い込む。
今回は、Hackの型チェッカー（hhvm typechecker）が関数型をどのように解釈し、HHVMのJITコンパイラがそれをいかに効率的なバイトコードに翻訳しているのか。その内部メカニズムと、型安全性の限界を突破する極限の知見を紐解く。
—
1. 関数型における変性の基本原則：なぜコールバックの引数は「反変」なのか
まず、言語設計の根底にある数学的・論理的必然性を確認する。
関数型 `(function(ArgType): ReturnType)` を扱う際、型チェッカーは以下の原則を厳格に適用する。
1. 戻り値は「共変（Covariant）」：期待される型よりも「具体的（派生している）」な型を返すことは安全である。
2. 引数は「反変（Contravariant）」：期待される型よりも「抽象的（基底である）」な引数を受け入れる関数でなければならない。
これを直感的なPHP/Hackのコードベースで思い出そう。もしあなたが「動物（Animal）」を受け取り「犬（Dog）」を返す関数を期待している場所に、「生き物（LivingThing）」を受け取り「プードル（Poodle）」を返す関数を渡せば、型安全性は崩壊する。
しかし、この関数型自体を別の高階関数の引数や戻り値として渡すとき、変性の方向は入れ子になり、複雑怪奇な様相を呈する。
—
2. 高階関数における Function Types の型制約と変性エラー
次のコードを見てほしい。大規模なイベント駆動型アーキテクチャや、非同期パイプライン処理の抽象化レイヤーで頻出するパターンだ。
<<__Strict__>>
namespace HackEngine\Core;
class Entity {}
class User extends Entity {}
class AdminUser extends User {}
// 高階関数：指定されたプロセッサを受け取り、処理を実行するパイプライン
final class Pipeline {
// ここに注目する：引数に「関数型」を受け取る
// この関数型自体の引数と戻り値にどのような制約がかかるのか？
public static function process(
User $input,
(function(User): Entity) $processor,
): Entity {
return $processor($input);
}
}
この設計において、もし呼び出し側が以下のようなコールバック関数を渡そうとしたとき、型チェッカーは何を根拠にエラーを吐き、あるいは通すのだろうか？
危険なコールバックの例
// Entity（基底）を受け取り、AdminUser（特異）を返す関数
function handleEntityToAdmin(Entity $e): AdminUser {
return new AdminUser();
}
// 実行
<<__EntryPoint__>>
function main(): void {
$user = new User();
// 型チェッカーはこの呼び出しを許可するべきか？
$result = Pipeline::process($user, fun(‘handleEntityToAdmin’));
}
結論から言えば、このコードはHackの型チェッカーによって正常にパスする。
なぜなら：
- 引数のチェック（反変）: パイプラインは `User` を渡す。コールバックは `Entity`（`User` のスーパータイプ）を受け取れるため、`User` が渡されても安全に処理できる。
- 戻り値のチェック（共変）: パイプラインは `Entity` が返ることを期待している。コールバックは `AdminUser`（`Entity` のサブタイプ）を返すため、受け取った側は安全に `Entity` として扱える。
—
3. HHVM内部における関数型とレイテンシの罠
型チェッカーの理論が分かったところで、次はHHVMのランタイム（低レイヤ）の話をしよう。
Hackのコードは、hhc（Hack Compiler）によってbytecode（HHBBCによる最適化を含む）にコンパイルされ、HHVMのTC（Translation Cache）上でJIT実行される。ここで重要なのは、「関数型（`function(…)`）」がランタイムにおいてどのように表現されているかという点だ。
低レイヤ表現とディスパッチコスト
静的言語であるC++やRustの関数ポインタ／クロージャとは異なり、Hack（およびPHP血統のVM）における第一級関数（First-class functions）やクロージャは、以下のオーバーヘッドを伴う。
1. クロージャオブジェクトのALLOCATION: 動的にキャプチャ変数を伴う場合、Heap上にオブジェクトが生成される。
2. 型シグネチャの検証（Runtime Type Checking）: `<<__Strict__>>` モードであっても、動的に渡されるコールバックが期待されるインターフェイス（引数・戻り値の型）を満たしているか、HHVMのVMインストラクション（`VerifyParamType` や `VerifyRetType`）レベルでの検証コストが発生する場合がある。
特に高階関数のループ内で頻繁にクロージャや関数型を渡す設計を行うと、JITのインライン展開（Inlining）の障壁となり、TCのヒット率が低下する。
限界を突破するためのアーキテクチャ知見：`memoize` との共存
高階関数に渡す関数型が複雑な変性制約を持つ場合、パフォーマンスのボトルネックになりやすい。これを回避しつつ、厳格な型システムを維持するための実践的テクニックが、「インターフェイスベースの関数オブジェクト（Functor Pattern）」の活用だ。
クロージャの代わりに、型安全なインターフェイスを実装したクラスを渡すことで、HHVMのJITは仮想メソッド呼び出し（VTABLE dispatch）の最適化を行いやすくなり、型チェッカーにとっても変性の解釈が極めて明確になる。
<<__Strict__>>
namespace HackEngine\Optimization;
// クロージャの代わりにインターフェイスを定義（極限のパフォーマンス追求）
interface IProcessor
public function __invoke(TIn $input): TOut;
}
final class UserToEntityProcessor implements IProcessor
public function __invoke(Entity $input): AdminUser {
// 最適化された処理ロジック
return new AdminUser();
}
}
このアプローチを取ることで、HHVMのプロファイラは型情報をより正確に追跡でき、JITコンパイラは動的な関数型のディスパッチコストを排除し、直接呼び出し（Direct Call）へと昇格させることが可能になる。
—
4. まとめ：厳格性とパフォーマンスの境界線で
Hackの `Function Types` における引数と戻り値の共変・反変制約は、単なる академическая（学問的）な型理論の遊戯ではない。それは、複雑化する巨大なコードベースにおいて、「予期せぬ型エラーをコンパイルタイムで完全に根絶する」ための最後の防壁である。
しかし、シニアエンジニアたる者、型チェッカーが通したからといって満足してはならない。その裏でHHVMの仮想マシンがどのようなバイトコードを生成し、メモリ上で何が起きているのかを脳内でトレースできてこそ、真にHackを掌握したアーキテクトと言える。
厳格な型システムを武器に、限界を超えた高パフォーマンスなシステムを構築し続けよう。