戻り値の「型」を曖昧にするな：HackにおけるTuple活用による堅牢なAPI設計
プロダクション環境で「配列の添字アクセス」が原因のランタイムエラーに遭遇したことはないか？ `$result[0]` が何であるかを脳内で記憶し続け、コードの変更のたびにその記憶を更新する……それはエンジニアリングではなく、ただの苦行だ。
HHVMのアーキテクチャにおいて、型チェッカー（hh_client）は単なる補助輪ではない。「型はドキュメントであり、かつ最強の契約である」。
今回は、Hackの `tuple` 型を駆使し、配列という「緩い器」を脱却して、コンパイル時に正当性が証明された複数戻り値のハンドリング術を伝授する。
—
なぜ「配列」を戻り値にするのが悪手なのか
PHPのレガシーな慣習として、複数の値を返す際に `array` を用いる手法がある。
// アンチパターン：これでは「何を返しているか」が型として明示されない
function fetchUserSession(int $id): array {
return [$userName, $isValid];
}
このコードの呼び出し側は、`$result[0]` が `string` なのか `int` なのかを型チェッカーに教える術を持たない。結果、`mixed` 型が蔓延し、`idx()` 関数で安全性を確認するか、あるいは無視して `Fatal error` を踏む未来が待っている。
Tupleがもたらす「型による静的保証」
Hackの `tuple` は、単なる順序付き集合ではない。「要素数」と「各位置の型」がコンパイル時に固定された、極めて軽量なデータ構造だ。HHVM内部では、配列よりも最適化されたメモリレイアウトで扱われる可能性が高く、パフォーマンスと安全性を両立できる。
実践：堅牢な複数戻り値の設計
以下のコードを見てほしい。非同期APIの結果と、その状態をタプルで返却する設計だ。
namespace App\Infrastructure;
// 戻り値を tuple で定義することで、呼び出し側は分解(Destructuring)を強制される
type UserFetchResult = (bool, ?string);
final class UserLoader {
public function fetchUser(int $id): UserFetchResult {
// データベースや外部APIとの疎通をシミュレート
if ($id <= 0) {
return tuple(false, null);
}
return tuple(true, "Hack_Master_User");
}
}
// 呼び出し側のコード
function processUser(int $id): void {
$loader = new UserLoader();
// 分解代入：ここでの型推論は極めて厳格。
// もしタプルの構造が変われば、即座にコンパイルエラーとなる。
list($success, $name) = $loader->fetchUser($id);
if (!$success) {
// エラーハンドリング
return;
}
// $name は ?string であると確定しているため、安全に扱える
echo “Welcome back, ” . ($name ?? “Guest”);
}
この設計がもたらす3つのメリット
1. コンパイル時の契約締結: `tuple` の要素数を変更した場合、呼び出し側のコードベース全体で型チェックが落ちる。つまり、バグを本番環境にデプロイする前にすべて排除できる。
2. IDEの補完と可読性: 配列と異なり、`tuple` は型シグネチャの一部であるため、エディタは「1番目の要素はboolである」という事実を正確に把握する。
3. HHVM最適化の恩恵: 構造が固定されているため、HHVMのJITコンパイラにとって最適化のヒントが豊富になる。配列のような動的なハッシュマップよりも、低レイテンシでの実行が可能だ。
注意点：Tuple vs Shape
「要素に名前を付けたい」という誘惑に駆られるかもしれない。その場合は `tuple` ではなく `shape` を検討せよ。
- `tuple` を使うべき場面: 戻り値の順序が論理的に明白で、一時的な「値のペア/トリプレット」を返す場合。（例：`tuple(Success, Data)`）
- `shape` を使うべき場面: 戻り値の項目数が多い、あるいは各要素の意味を明示的なラベルで区別したい場合。
最後に：型をサボるな
優秀なエンジニアは、コードを書くときに「どう動くか」ではなく「どうすれば不正な状態をコンパイルレベルで排除できるか」を考える。
`tuple` を使いこなすことは、HHVMの型システムと対話することだ。配列という「緩さ」に甘んじるか、`tuple` という「厳格さ」でシステムの堅牢性を担保するか。答えは明白だろう。
今すぐコードベースを開き、`array` で返されている関数のシグネチャを `tuple` に書き換えてみよ。その瞬間、君のコードからまた一つ、潜在的なランタイムエラーの芽が摘まれるはずだ。