【Hack言語・型設計の極み】Tuple型による複数戻り値の分解：配列ベースの地獄からの脱却
コードレビューをしていると、未だにPHP時代の悪しき慣習を引きずったコードに出くわすことがある。
その代表格が、複数の値を返すために配列（`array`）や連想配列を返し、呼び出し側でマジックナンバーやキー名に依存して値を取り出すパターンだ。
// 【アンチパターン】配列による複数戻り値。型が曖昧であり、インデックスのズレやタイポの温床となる。
async function fetch_user_data_legacy(int $id): Awaitable
// … 何らかのDB/APIフェッチ
return tuple(‘Alice’, 30, ‘alice@example.com’); // arrayにキャストされてしまう
}
// 呼び出し側
$result = await fetch_user_data_legacy(1);
$name = $result[0]; // 0番目ってなんだっけ？
$age = $result[1]; // インデックスの変更に極めて脆弱
HHVMの厳格な静的型システム（Strict Mode）を運用する我々にとって、このようなコードは技術的負債以外の何ものでもない。配列のインデックスアクセスは型チェッカーの目をかいくぐり、本番環境での致命的なRuntime Exceptionを引き起こす。
今回は、Hackの`Tuple`型とリスト代入（List Assignment）を駆使し、パフォーマンスを犠牲にせず、型安全性と保守性を極限まで高めた複数戻り値の設計パターンを伝授する。
—
1. なぜ「配列ベースの戻り値」は悪なのか？
PHPおよび移行期のHackコードにおいて、複数戻り値が必要な場合に配列を使う設計が散見される。しかし、以下の理由からプロダクションコードでは絶対に避けるべきだ。
1. 型情報の欠落: `array
2. マジックインデックスへの依存: `$data[0]`, `$data[1]` のようなコードは、関数側の戻り値の順序変更に対して極めて脆弱であり、リファクタリングの障害になる。
3. 認知負荷の増大: 開発者は常に「何番目に何のデータが入っているか」を暗記、あるいは関数定義を往復して確認し続けなければならない。
これらを一撃で解決するのが、HackのTuple（タプル）型である。
—
2. Tuple型による堅牢なデータ構造の定義
HackのTupleは、固定長かつ各要素が異なる型を持つことが保証されたプリミティブな複合データ型である。
<<__Strict>>
namespace Hack\Architect\Examples;
// Tuple型を用いた厳格なシグネチャ
type UserTuple = (string, int, string);
Tupleは配列とは異なり、HHVMの内部VM（HHBC）レベルで最適化された構造体に近い振る舞いをする。動的な要素追加や削除はできないが、「固定された複数の異なる型の値を、オーバーヘッドなく返す」という目的に対しては、クラスを定義するよりも軽量かつ高速に動作する。
—
3. 実践：非同期API連携におけるTuple型とリスト代入の極意
実際のWebアプリケーション開発において、複数エンティティの並行フェッチと分解は日常茶飯事だ。
以下のプロダクションコードを見てほしい。非同期処理（`Awaitable`）とTuple、そしてリスト代入を組み合わせた、最も美しく堅牢な設計パターンである。
<<__Strict>>
namespace Hack\Architect\Examples;
type UserProfile = shape(
‘id’ => int,
‘name’ => string,
);
type AccountMetrics = shape(
‘login_count’ => int,
‘is_active’ => bool,
);
class UserDomainService {
/
- ユーザープロファイルとメトリクスを並行取得し、Tupleで返す。
- 戻り値の型が厳格に (UserProfile, AccountMetrics) に固定される。
/
public async function fetchUserCompositeDataAsync(int $userId): Awaitable<(UserProfile, AccountMetrics)> {
// 非同期処理の並行実行（Concurrent Execution）
concurrent {
$profile = await $this->fetchProfileAsync($userId);
$metrics = await $this->fetchMetricsAsync($userId);
}
// Tupleとして返す。型チェッカーが要素の型と順序を完全に検証する。
return tuple($profile, $metrics);
}
private async function fetchProfileAsync(int $userId): Awaitable
// DBモック
await \HH\Asio\usleep(10000);
return shape(‘id’ => $userId, ‘name’ => ‘Cyber Architect’);
}
private async function fetchMetricsAsync(int $userId): Awaitable
// DBモック
await \HH\Asio\usleep(10000);
return shape(‘login_count’ => 142, ‘is_active’ => true);
}
}
呼び出し側での優美な分解（List Assignment）
この設計の真価は、呼び出し側にある。返されたTupleは、リスト代入構文を用いることで、変数名に直接かつ型安全にバインドできる。
<<__Strict>>
namespace Hack\Architect\Examples;
async function handle_user_request(int $userId, UserDomainService $service): Awaitable
// Tupleの戻り値をそのままリスト代入でキャプチャ
// $profileは UserProfile型、$metricsは AccountMetrics型として自動推論される
list($profile, $metrics) = await $service->fetchUserCompositeDataAsync($userId);
// インデックスアクセスは不要。IDEの補完も完全に効く。
\HH\Asio\print_dataf(
“User: %s (Active: %s)\n”,
$profile[‘name’],
$metrics[‘is_active’] ? ‘YES’ : ‘NO’
);
}
ここで配列を使っていた場合、`list($a, $b)` の中身の型は曖昧になりがちだが、Tupleを返す関数シグネチャであれば、静的型チェッカーが完全に型を追跡する。万が一、関数側でTupleの要素順序を変更し忘れたり型を変えたりした場合、コンパイルタイム（hh_client）で即座に検知される。
—
4. パフォーマンスとアーキテクチャ上の注意点
テクニカルリードとして、パフォーマンスや設計上のトレードオフについても言及しておこう。
1. DTO（Data Transfer Object）クラスとの使い分け
- Tupleを使うべき場面: 密結合なスコープ内（同一モジュール内やプライベートメソッド間）で、一時的に複数の値をまとめたい場合。クラス定義のボイラープレート（コンストラクタやプロパティ定義）を削減できる。
- ShapeやClassを使うべき場面: ドメインモデルとして外部境界（APIレスポンスや永続化層）を跨ぐ場合、あるいはビジネスロジックやメソッドを持たせる場合。Tupleは構造的な名前を持たないため、パブリックなAPIの戻り値として乱用するとコードの意図が読みづらくなる。
2. HHVMのメモリ効率
Tupleは軽量であるため、連想配列（Map/Dict）のようにキー文字列のハッシュ計算やメモリ割り当てのオーバーヘッドがない。高スループットが求められるAPIエンドポイントにおいて、GC（ガベージコレクション）の負荷を軽減する有効な手段となる。
—
5. まとめ
配列ベースの複数戻り値は、動的言語の遺物であり、厳格な型システムを持つHackにおいては「バグの温床」でしかない。
- 複数の値を返すときは `array` ではなく `Tuple型` を採用する。
- 呼び出し側では `list(…)` を用いて意図を明確にし、マジックインデックスを排除する。
- 型チェッカーを味方につけ、コンパイル時にバグをねじ伏せる。
このデザインパターンをチームに浸透させれば、コードベースの堅牢性は劇的に向上する。次のコードレビューでは、配列を返している箇所を見つけたら、迷わずこのTupleパターンへのリファクタリングを要求してほしい。