【実務・中級編】Hackの`darray`と`varray`から`dict`と`vec`への移行：型システムの進化を追う – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

Hack言語の進化を解剖する：darray/varrayからdict/vecへの移行が意味する「型安全性の深化」

Hackの歴史を振り返ることは、PHPという動的型言語の混沌から、いかにして現代的な堅牢性を備えた実行時環境を構築してきたかを学ぶことに他ならない。

多くのエンジニアが「単なる新しい構文」と誤解している`dict`や`vec`への完全移行だが、これはHHVM（HipHop Virtual Machine）のJITコンパイラおよび型チェッカーの挙動において、劇的な最適化とバグの撲滅をもたらす「パラダイムシフト」である。

今回は、なぜ我々が`darray`や`varray`を過去の遺物としたのか。そして、現代のプロダクションコードにおいて、どのようにコレクションを設計すべきかを深層から解説する。

—

1. なぜ「配列（Array）」は悪だったのか？

かつてのPHPの配列は、連想配列であり、リストであり、セットであり、さらには順序付きマップでもあった。この「何でも入る」柔軟性は、型チェッカーにとっては悪夢だ。

共変性の欠如: `darray`や`varray`は、型システム上、常に「Any的な何か」として扱われがちだった。
構造的欠陥: 実行時に「配列の途中にキーが存在するか」を常にチェックしなければならず、HHVMがインラインキャッシュを最適化する際の障壁となっていた。

`dict`と`vec`への移行は、単なるシンタックスシュガーではない。「メモリレイアウトの固定化」である。HHVMは`vec`がプリミティブな連続メモリであることを確信できるため、型推論の段階で不要な型チェックコードを削除し、マシンコードレベルでの最適化を可能にする。

—

2. 厳格なモード（Strict Mode）で書くべき「美しいコード」

プロダクション環境では、型エラーをコンパイルタイム（`hh_client`の実行時）に完全に排除することが大前提だ。以下に、現代的なHackにおけるコレクション操作のベストプラクティスを示す。

不変性を担保するデザインパターン

データクラスとコレクションを組み合わせる際、`readonly`プロパティと`vec`/`dict`を組み合わせるのが最も堅牢だ。

<<__ConsistentConstruct>>
abstract class BaseResponse {
// 外部からの変更を許さない不変コレクション
public function __construct(
public readonly vec $ids,
public readonly dict $metadata,
) {}
}

final class UserResponse extends BaseResponse {
public static function fromRaw(mixed $data): this {
// ここで型アサーションを通すのが、堅牢なAPI連携の第一歩
// 実行時に構造を確定させ、以降は型安全に扱う
if (!($data is shape(‘ids’ => vec, ‘metadata’ => dict))) {
throw new InvalidArgumentException(“Invalid API response structure”);
}
return new self($data[‘ids’], $data[‘metadata’]);
}
}

なぜこの実装が優れているのか？

1. 境界（Boundary）での検証: APIレスポンスという「信頼できない外部データ」を、`is`演算子を用いて`shape`で定義された構造へ強制的に型変換している。
2. 不変性の保証: `readonly`を付与することで、後続のロジックで誤ってデータが書き換えられるリスクを言語レベルで排除している。
3. 最適化: `vec`と明示することで、HHVMはこれを最適化されたヒープ上の連続領域として扱い、ポインタ演算を最小化する。

—

3. 実務で遭遇する「罠」：パフォーマンスの最適化

開発中に、「型を合わせるのが面倒だから」と`dict`や`vec`を型引数なし（`dict`）で定義するコードを見かけることがある。これは重大なパフォーマンス劣化の元凶だ。

アンチパターン：型を放棄するコード

// 悪い例: 型チェッカーの恩恵を捨てている
function processData(dict $data): void {
// $dataの中身が不明なため、HHVMは実行のたびに型チェックのオーバーヘッドを背負う
}

正しいアプローチ：型システムを活用する

型システムは「制限」ではなく「武器」だ。以下のように、Genericsを徹底的に活用することで、HHVMの推論能力を最大限に引き出せる。

// 良い例: Genericsで制約を明示
function processData(dict $data): void {
// Tがarraykey（string or int）に限定されるため、
// HHVMはハッシュテーブルの高速なルックアップを安全にインライン化できる
foreach ($data as $key => $value) {
// ここでの$keyは型安全
}
}

—

4. チーフアーキテクトからの助言

`darray`や`varray`から`dict`と`vec`への移行は完了したが、それは終わりではない。本当のHackの力は、「型システムが何を理解し、何を見落としているか」を常に意識することにある。

コンテナのコピー: `vec`や`dict`は値型（Value Type）として扱われる。関数に渡す際は参照渡しを考えるのではなく、必要に応じて`readonly`を活用し、無駄なコピーを避ける意識を持つこと。
形状（Shape）の活用: 不特定多数のキーを持つ`dict`よりも、構造が明確な`shape`を優先せよ。`shape`はコンパイル時にメモリレイアウトが決まるため、アクセス速度が`dict`よりも高速であるケースが多い。

コードを記述する際、常に自問してほしい。「この型定義は、HHVMの最適化を助けているか？それとも単なる保険に過ぎないか？」と。

型システムを掌握したものだけが、Web開発という戦場で、最も速く、そして最も壊れないコードを届けることができる。さあ、型チェッカーを最大限に働かせ、美しいコードを書いてくれ。