こんにちは！フルスタックエンジニアの先輩です。今日は、Hack言語における「型安全な辞書操作」の心臓部、`Shapes::idx`と`Shapes::removeKey`の世界へご案内しますね。
他の言語（例えばJavaScriptやPHPの連想配列など）からHackの世界に飛び込んできたとき、こんなモヤモヤを感じたことはありませんか？
「ただのキーバリューの集まりなのに、なんでこんなに型がうるさいんだろう？」って。
でも、ここをクリアすれば、あなたの書くコードはバグの温床から「鉄壁の要塞」へと生まれ変わります。HHVM（HipHop Virtual Machine）の圧倒的なパフォーマンスと、妥協なき静的型チェッカーの恩恵をフルに受けるための極意を、一緒に紐解いていきましょう！
—
1. Hackの「Shape（シェイプ）」ってそもそも何？
通常の `array` や `dict` が「何を入れてもいい（あるいは同じ型のものしか入れられない）」のに対して、Shapeは「このキーには、絶対にこの型の値が入る」という構造（Shape）をコンパイル時に完全保証するための特殊な型です。
例えば、ユーザー情報を表すShapeを定義してみましょう。
// ユーザーの構造を厳格に定義するShape型
type UserShape = shape(
‘id’ => int,
‘name’ => string,
‘is_active’ => bool,
);
この `UserShape` は、HHVMの型チェッカーから見ると、「キーとして `’id’`（int型）, `’name’`（string型）, `’is_active’`（bool型）の3つを必ず持つデータ構造」として厳密に認識されます。
—
2. 安全な値の取り出し：`Shapes::idx` の正体
Shapeのデータから値を取り出すとき、単に `$user[‘age’]` のようにアクセスしようとすると、型チェッカーに怒られてしまいます。「おいおい、そんなキーは `UserShape` に定義されてないぞ！」と。
また、存在するかどうかわからないキーにアクセスする場合や、オプショナルなキーを扱うときに大活躍するのが `Shapes::idx` です。
基本的な使い方とコードの意味
<<__Strict>>
namespace MyProject;
type UserShape = shape(
‘id’ => int,
‘name’ => string,
?’nickname’ => string, // ‘?’ がついているので、このキーは存在しないかもしれない（オプショナル）
);
function printUserNickname(UserShape $user): void {
// Shapes::idx(対象のshape, キー名, デフォルト値)
// キーが存在しない場合は、第3引数のデフォルト値（ここでは ‘名無し’）が返る
$nickname = Shapes::idx($user, ‘nickname’, ‘名無し’);
// $nickname は自動的に string 型として推論されます！
echo “ニックネーム: ” . $nickname . “\n”;
}
`Shapes::idx` の裏側：型チェッカーはどう動いているか？
ここで重要なのは、`Shapes::idx` が単なる便利なヘルパー関数ではないという点です。これはHHVMの型チェッカー（Typechecker）と深く結びついた「総称型（Generics）のマジック」です。
型チェッカーは、`Shapes::idx` を呼び出した瞬間に以下のような頭の働きをしています。
1. 「お、第1引数のShapeには `’nickname’` というキーが定義されているな」
2. 「その値の型は `string` だな」
3. 「じゃあ、返り値の型も絶対に `string`（またはデフォルト値の型）に固定してやろう」
だからこそ、返り値を受け取ったあとに「これって本当に文字列だっけ？」と心配する必要が一切なくなるんです。ここが、緩い動的型付けのPHPとは決定的に違う、Hackの美しさですね。
—
3. 安全な破壊的（に見える）操作：`Shapes::removeKey`
「辞書から特定のキーを取り除きたい」という場面、よくありますよね。例えば、機密情報を外部APIに送る前に、特定のキーを削除したい時などです。
ここで初心者がやりがちなのが、元のShapeをそのままイジろうとして型エラーを踏むパターンです。Hackでは、Shapeの構造は基本的にイミュータブル（変更不可）として扱われます。
そこで登場するのが `Shapes::removeKey` です。
具体的なコードと挙動
<<__Strict>>
namespace MyProject;
type UserData = shape(
‘id’ => int,
‘password_hash’ => string,
‘name’ => string,
);
function sanitizeUser(UserData $user): void {
// 元の配列から ‘password_hash’ を削除した新しい構造を作る
// 注意: Shapes::removeKey は「参照渡し」で元の変数自体を書き換えます
Shapes::removeKey(inout $user, ‘password_hash’);
// この瞬間、変数 $user の型は自動的に以下のように変化します！
// 変化後: shape(‘id’ => int, ‘name’ => string)
// 以下はコンパイルエラーになります（もうキーが存在しないから）
// echo $user[‘password_hash’];
}
🧠 ここがポイント：`inout` キーワードと型システムの連動
お気づきでしょうか？ 引数に `inout $user` と渡されていますね。
Hackの `Shapes::removeKey` は、渡されたShapeから指定したキーを型レベルで削ぎ落とし、変数の型そのものをアップデートします。
つまり、`Shapes::removeKey` を実行したあとのコードでは、型チェッカーは「もうそのキーはこのデータの中に存在しない」という前提でその後のコードを検査します。もしその後に削除したキーにアクセスしようものなら、実行するまでもなく、IDEやビルドの段階で赤くエラーを吐いて教えてくれるのです。
—
4. 陥りやすい文法エラーと対策
よくあるつまずきポイントを先回りしてクリアしておきましょう！
罠1: 定義されていないキーを `Shapes::idx` で探してしまう
type Point = shape(‘x’ => int, ‘y’ => int);
function getZ(Point $p): int {
// エラー！ ‘z’ なんてキーは Point に存在しないため、型チェッカーが怒ります
return Shapes::idx($p, ‘z’, 0);
}
対策: キーが存在しない可能性があるなら、最初からShapeの定義に `?’z’ => int` のようにオプショナル記号（`?`）を付与しましょう。
罠2: 戻り値の型ミスマッチ
type Config = shape(‘timeout’ => int);
function getTimeout(Config $config): string {
// エラー！ ‘timeout’ は int型 なのに、第3引数（デフォルト値）に string型 (’30秒’) を渡しているため型不一致になります
return Shapes::idx($config, ‘timeout’, ’30秒’);
}
対策: デフォルト値の型は、Shape内で定義されている値の型と完全に一致させてください。型安全の基本ですね！
—
まとめ：Hackの厳格さは、未来のあなたへの最高の贈り物
今回は `Shapes::idx` と `Shapes::removeKey` を通して、Hackの型安全な辞書操作の裏側を覗いてみました。
- `Shapes::idx`: 存在するか分からないキーやオプショナルなキーから、安全に型を保証しながら値を取り出す。
- `Shapes::removeKey`: 実行時にキーを安全に削除しつつ、変数の型そのものを次のステップへ向けて再構築（縮小）する。
一見すると「制約が多くて面倒くさい」と感じるかもしれない厳格な静的型付けですが、これは大規模なアプリケーション開発において「意図しないバグ」をビルド段階で100%駆逐するための強力な武器です。
ここをクリアできれば、あなたはもうHackのコアな思想をしっかりと理解できています。
自信を持って、次のコードを書きに行きましょう！それではまた！