タプルは「ただの配列の親戚」ではない：HHVMの型システムをハックする複数戻り値設計
コードレビューをしていて、いまだにこんなコードを見かけるたびに私は頭を抱えたくなる。
// 悪夢のような動的配列の返却
async function fetchUserData(int $id): Awaitable
// …
return tuple($name, $metadata);
}
おいおい、待ってくれ。ここはPHPの泥沼ではない。厳格な静的型システムとJITコンパイルの極限であるHackの世界だ。なぜ `array` や `shape` で茶を濁す？
Webエンジニアの君たちが日々直面する非同期API連携やデータベースからのデータフェッチ。そこで「複数の戻り値」を扱う際、曖昧な配列や不毛なDTO（Data Transfer Object）クラスを乱立させていないか？
今回は、HackのTuple（タプル）型を武器に、型チェッカーを完全手懐け、パフォーマンスと保守性を極限まで高めるための設計論を叩き込む。
—
なぜ「配列」や「形状（Shape）」ではなく「タプル」なのか？
複数戻り値を扱う際、選択肢はいくつかある。それぞれの挙動をHHVMのアーキテクチャの観点から見極めよう。
1. `array` (緩い配列): 論外だ。要素の型がバラバラになりやすく、型チェッカー（hhvm）はこれを適切に追跡できない。ランタイムエラーの温床になる。
2. `shape`: 構造体的なアプローチとして優れているが、キー名（`’name’ => …`）を持つため、オーバーヘッドが発生する。また、単純な「順序に意味がある対のデータ」に対しては冗長だ。
3. `tuple`: コンパイル時に固定長・固定位置の型が完全に保証される。HHVMの内部表現においても極めて効率的にメモリ上に配置され、不要なハッシュルックアップが発生しない。
Strict Mode (`<
—
実践：プロダクションコードで示す堅牢な非同期API連携
では、実際のシステム開発を想定したコードを見せよう。
外部APIへの非同期リクエストを行い、その「レスポンスデータ」と「レートリミット（残り回数）」の2つを同時に、かつ完全に型安全に返却・処理するコンポーネントだ。
<
namespace HackArchitect\Api;
use namespace HH\Asio;
use namespace HH\Lib\Math;
/
- 外部APIクライアントのモック
- 戻り値にTupleを使用し、データ本体とメタデータを厳密に型付けする。
/
final class SecureApiClient {
// タプルによる複数戻り値: [厳格なドメインモデル, 残りレートリミット数]
public async function fetchUserAndRateLimit(int $userId): Awaitable<(UserResponse, int)> {
// 非同期での外部フェッチをシミュレート
$rawResponseData =, $remainingLimit = await Asio\v(tuple(
$this->callUserApi($userId),
$this->fetchRateLimitHeader()
));
$user = UserResponse::fromArray($rawResponseData);
// 完璧に型安全なタプルを返す
return tuple($user, $remainingLimit);
}
private async function callUserApi(int $userId): Awaitable
await Asio\usleep(10000.0); // 10ms delay
return dict[‘id’ => $userId, ‘name’ => ‘Kaelen’, ‘role’ => ‘TechLead’];
}
private async function fetchRateLimitHeader(): Awaitable
await Asio\usleep(5000.0); // 5ms delay
return 499;
}
}
final class UserResponse {
public function __construct(
public int $id,
public string $name,
public string $role,
) {}
public static function fromArray(dict
// 厳格なキャストとバリデーション
return new self(
/ HH_FIXME[IncompatibleType] 簡略化のためキャスト省略 /
(int)$data[‘id’],
(string)$data[‘name’],
(string)$data[‘role’],
);
}
}
—
呼び出し側での華麗なタプル分解（Destructuring）
このコンポーネントを消費する側を見てほしい。
ここで重要なのは、余計なボイラープレート（一時変数やDTOのインスタンス生成）を書くことなく、美しく変数をバインドできる点だ。
<
namespace HackArchitect\Service;
use namespace HackArchitect\Api;
use namespace HH\Asio;
final class UserProcessor {
public function __construct(private Api\SecureApiClient $apiClient) {}
public async function process(int $userId): Awaitable
// タプルの分解アサインメント
// 型チェッカーは $user を UserResponse型、 $limit を int型 と完全に静的解析する
list($user, $limit) = await $this->apiClient->fetchUserAndRateLimit($userId);
if ($limit < 10) {
// レートリミット逼迫時のアラート処理
\Cout\print_string("WARNING: Rate limit is critically low: {$limit}\n");
}
\Cout\print_string("Processing user: {$user->name} [Role: {$user->role}]\n”);
}
}
どうだ？ コードの意図がこれ以上ないほど明確に読み取れるはずだ。
配列のインデックス（`$result[0]`, `$result[1]`）にアクセスするような、バグの温床となるマジックナンバー的なコードは一切排除されている。`list()` による分解は、Hackの型チェッカーによって完全に守られている。
—
チーフアーキテクトからの警鐘：パフォーマンスと設計の罠
ここで一つ、実務におけるパフォーマンスとメモリ管理の知見を共有しておこう。
タプルは非常に軽量で強力だが、「過剰なネスト」は避けるべきだ。
例えば、`((int, string), (bool, (float, string)))` のような多重タプルを設計した瞬間、コードの可読性は崩壊し、メンテナとしての次の開発者が呪いの言葉を吐くことになる。
- 原則 1: タプルの要素数は原則として「2つ、あるいは最大でも3つ」にとどめよ。それ以上のデータ構造が必要になった場合は、迷わず `class` または `readonly` なデータ構造を定義しろ。
- 原則 2: HHVMのJITはタプル構造を極めて効率的に最適化するが、動的な型（`mixed`）をタプルに混ぜ込むのは厳禁だ。`tuple(int, mixed)` と書いた瞬間、JITの最適化効力が低下し、ボックス化（Boxing）のオーバーヘッドが発生する。
—
結びにかえて
Hack言語を採用しているプロジェクトにおいて、型は単なる「エラーを防ぐための保険」ではない。「コードの意図を正確にコンパイラとチームメイトに伝えるための最も美しいドキュメント」なのだ。
配列でデータを曖昧に受け渡す時代は終わった。
Tuple型をマスターし、静的解析の恩恵を極限まで引き出した堅牢なプロダクションコードを、今日から君の現場に導入してほしい。