【入門編】Hackの『Shapes::idx』と『Shapes::removeKey』の裏側：型安全な辞書操作の限界と回避策 – Hack言語コア・静的型システムとHHVMのアーキテクチャ解析バイブル

こんにちは！HHVMの内部構造やHackの静常時型システムの裏側まで愛してやまない、君の先輩エンジニアです。

他の言語、例えばPHPやJavaScriptからHackの世界へ飛び込んできた君なら、きっとこう思ったことがあるはず。「動的なキーを持つ連想配列を安全に扱いたいけれど、型チェッカーが厳しすぎてどう書けばいいかわからない！」ってね。

大丈夫。今日はHackが誇る最強の武器である「Strict Mode」と、その中で動的な辞書操作を行うための必須テクニック`Shapes::idx`と`Shapes::removeKey`の裏側を、一緒に深く紐解いていくよ。ここをクリアすれば、Hackの型システムの機微が手に取るようにわかるようになるからね。

—

1. Hackの「Shape」ってそもそも何だろう？

PHPの連想配列（`array`）は非常に自由で便利ですが、裏を返せば「どんなキーに何の型が入っているか分からない」という型安全性のブラックボックスでした。

そこでHackでは、構造化された配列を表現するために Shape（シェイプ） という概念を導入しました。

// 例えば、ユーザー情報を表すShapeの定義です
type User = shape(
‘id’ => int,
‘name’ => string,
?‘email’ => ?string, // オプショナルなキー
);

Shapeは、コンパイル時（正確には型チェッカーの実行時）に「この辞書にはどのキーが存在し、それぞれ何型なのか」を完全に固定します。だから、存在しないキーにアクセスしようとしたり、違う型を代入しようものなら、型チェッカーが容赦なく赤線を引いて教えてくれるんです。

—

2. だけど、動的にキーを扱いたい時があるよね？

厳格なのは素晴らしいことなんだけれど、実際の開発ではこんなシチュエーションに出会います。

「外部APIから受け取ったJSONデータ、どのキーが含まれているか実行時までわからないよ！」
「オプショナルなキーを取り出したいけれど、いちいち存在チェックを書くのが面倒だな…」

そんなとき、素朴に `io` や配列の鍵アクセスを使おうとすると、Hackの厳格な型チェッカー（Strict Mode）はこう怒り出します。
> “The index ‘xxx’ may not exist in this shape.” （このキーはShapeに存在しないかもしれないよ！）

ここで登場するのが、安全に辞書を操作するためのビルトイン関数、`Shapes::idx` と `Shapes::removeKey` なんです。

—

3. `Shapes::idx` の裏側：安全な値の取り出し方

まずは `Shapes::idx` の基本的な使い方を見てみましょう。

<>
namespace HackMasterclass;

type Config = shape(‘host’ => string, ‘port’ => int);

function getPort(Config $config): int {
// ‘port’ キーの値を取り出す。もし無ければデフォルト値の 80 を返す
return Shapes::idx($config, ‘port’, 80);
}

何が起きているの？（型チェッカーの視点）

一見ただの便利関数に見えますが、HHVMと型チェッカーの内部では高度な型推論が行われています。

1. 存在しないかもしれないリスクの調停:
`Shapes::idx($shape, ‘key’, $default)` は、指定したキーがShapeに定義されていればその型を、オプショナルであれば「値またはnull」を、定義すらない場合は安全にデフォルト値を返すように型がオーバーロードされています。
2. 実行時オーバーヘッドの回避:
HHVMのJITコンパイラは、これが単なるキーアクセスに安全なフォールバックを加えたものであると理解し、極めて高速なバイトコードにコンパイルします。

—

4. `Shapes::removeKey` の裏側：イミュータブルな発想でのキー削除

次に、Shapeから特定のキーを安全に取り除く（削除する）`Shapes::removeKey` です。

ここで一つ、Hackの重要な哲学を伝えておきます。「Hackは基本的にデータの不変性（Immutability）を好む」ということです。

<>
namespace HackMasterclass;

type UserData = shape(‘id’ => int, ‘token’ => string, ‘name’ => string);

function sanitizeUser(UserData $user): shape(‘id’ => int, ‘name’ => string) {
// ‘token’ キーを削除した新しい Shape を返す
Shapes::removeKey(inout $user, ‘token’);

return $user;
}

ここに注目：`inout` キーワードの存在

`Shapes::removeKey` の第一引数には `inout` がついていますね。
これは、「変数を破壊的に（その場で）書き換えますよ」というHackの厳格な合図です。型チェッカーは、この操作の前後でShapeの型定義（構造）がどう変化したかを完璧に追跡します。

`’token’ => string` というキーが取り除かれた結果、戻り値の型と見事に一致するかどうかを、型チェッカーがコンパイル時に検証してくれるのです。

—

5. 型安全な辞書操作の限界と、実践的な回避策

さて、ここからが本題。型チェッカーの裏側まで知る君にこそ伝えたい「限界」と、そのスマートな「回避策」です。

🚨 限界：完全に動的なキー名（String変数）は扱えない

Shapeは「構造の固定」が正義です。そのため、以下のようなコードを書くと型チェッカーに怒られます。

// ❌ ＮＧパターン：変数に入った動的な文字列をキーとしてShapes::idxに通す
function getDynamicValue(Config $config, string $dynamicKey): mixed {
// 型チェッカーは $dynamicKey が Config に存在するか静的に検証できないためエラーになる
return Shapes::idx($config, $dynamicKey);
}

💡 回避策：本当に動的なデータなら `Dict` を使おう！

もしキーが完全に動的で、コンパイル時に予測できないのであれば、それはもはや「Shape」ではなく、純粋なコレクションである `Dict` や `Map` の領域です。

// ⭕ ＯＫパターン：動的なキーを扱うなら Dict に逃がす
function getDynamicValue(Dict $bag, string $dynamicKey): mixed {
// Dictであれば、実行時のキー存在チェックと組み合わせて安全に扱える
if (C\contains_key($bag, $dynamicKey)) {
return $bag[$dynamicKey];
}
return null;
}

Shapeを使うべき場面: ユーザープロフィールやAPIリクエストなど、「構造（キーの名称と型）がドメインとして決まっているもの」。
Dictを使うべき場面: 設定ファイルのパース結果や、キーが完全に流動的な「ただの辞書データ」。

この使い分けができるようになると、Hackの型システムと見事に意思疎通ができるようになりますよ。

—

まとめ

今回は、Hackの `Shapes::idx` と `Shapes::removeKey` の裏側にある型チェッカーの挙動と、動的辞書操作の限界について解説しました。

`Shapes::idx` は、コンパイル時の安全性を保ちながら、安全にオプショナルな値やデフォルト値へアクセスするための強力な架け橋。
`Shapes::removeKey` は、`inout` を伴ってShapeの構造変化を型チェッカーに正確に伝えながらデータを加工する仕組み。
完全に動的なキーを扱う場合は、無理にShapeを使わず `Dict` 型へシフトする。

ここをクリアすれば、Hackの厳格な世界で迷子になることはもうありません。型チェッカーは君の邪魔をする敵ではなく、最高のコード品質を守ってくれる心強い相棒ですからね。

それじゃあ、次のコードレビューでも最高のHackコードを書くのを期待しているよ！