配列（Array）の悪夢から脱却せよ：HackにおけるTuple型による「型安全な多値返却」の極意
Hackを愛する諸君、コードを書いているか？
PHPから派生したこの言語が、なぜ「堅牢なシステム」を構築する上で他の追随を許さないのか。その答えは、HHVMのJITエンジンが生成する機械語の効率性にあるのではない。「型チェッカーが、開発者の脳内の曖昧さを一切許容しない」という、その厳格さにある。
今日扱うのは、現場のコードベースに蔓延る「配列による複数値の返却」という悪習だ。これは型システムの崩壊を招く第一歩であり、バグの温床でしかない。なぜ我々がわざわざ`<<__Strict>>`を冠するのか。その本質を理解し、Tuple型で堅牢なコードを再構築する方法を伝授する。
—
1. なぜ「配列（array）」での返却は悪なのか
実務でよく見かける、このようなコードを想像してほしい。
// アンチパターン：何が入っているか実行時まで不明な地雷
function fetchUserSession(): array
return [
‘id’ => 123,
‘status’ => ‘active’,
];
}
このコードの何が問題か？
1. 型推論の敗北: `$data[‘id’]` にアクセスする際、型チェッカーはそれが `int` なのか `string` なのか、あるいはそもそもキーが存在するのかを保証できない。
2. 保守性の欠如: キー名をタイポしても静的解析では検知できない。プロダクションで `undefined index` が発生して初めて気づくことになる。
配列は「同じ型を持つデータの集合（コレクション）」を扱うための構造だ。異なる意味を持つ値を無理やり詰め込むコンテナではない。
—
2. Tuple（タプル）がもたらす「静的な契約」
Tupleは、「順序付けられた固定長かつ異種混合の型を持つ集合」だ。Hackの型システムにおいて、Tupleは非常に強力な武器になる。コンパイル時にサイズと各要素の型が厳密に検証されるため、実行時のオーバーヘッドなしに「型安全な多値返却」を実現できる。
実践的なプロダクションコード例
非同期API連携やデータベースアクセスにおいて、結果とエラーを同時に返す設計を考えてみよう。
<<__Strict>>
namespace App\Infrastructure;
/
- Tuple型を使用して、結果(Data)とエラー(Exception)を明示的に返す。
- これにより、呼び出し元は必ず両方のケースを考慮しなければならなくなる。
/
type Result
class UserAuthenticator {
public function authenticate(string $token): Result
try {
// 外部APIやDBへのアクセス…
$userId = 123;
return tuple($userId, null); // 成功時は結果とnull
} catch (\Exception $e) {
return tuple(0, $e); // 失敗時はデフォルト値(0)と例外
}
}
}
// 利用側
function handleRequest(string $token): void {
$auth = new UserAuthenticator();
// 分解代入(Destructuring)で安全かつ簡潔に受け取る
list($userId, $error) = $auth->authenticate($token);
if ($error !== null) {
// コンパイラはここで $error が null でないことを型推論で理解する
echo “Auth failed: ” . $error->getMessage();
return;
}
echo “Welcome, User ID: ” . $userId;
}
—
3. なぜこれが「美しい」設計なのか
この設計には、アーキテクトとして見逃せない3つのメリットがある。
① 網羅性の強制（Exhaustiveness）
もし戻り値が単なる配列であれば、開発者は適当に値を抽出して処理を進めてしまうだろう。しかし、Tupleで型を定義し、適切に型推論させることで、「エラーが発生したケース」を処理しないコードは、HHVMの型チェッカーがビルドを通さない。
② 実行時オーバーヘッドの最小化
HHVMのアーキテクチャにおいて、Tupleは固定長配列として最適化される。連想配列（Map）のようなハッシュテーブル探索のコストは発生しない。メモリ使用量は最小限であり、ホットパスを通るコードにおいて圧倒的なパフォーマンスを発揮する。
③ IDEの補完と可読性
`$data[‘user_id’]` と書くのと、`$userId` という名前の変数を受け取るのとでは、認知負荷が全く違う。Tupleは、関数の戻り値に「名前」を与えるのと同等の可読性を提供する。
—
4. チーフアーキテクトからの助言：いつ使うべきか
Tupleは万能ではない。以下の指針を守れ。
- 2〜3要素まで: 4つ以上の値が必要な場合は、Tupleではなく `class` (または `readonly record` / `shape`) を定義しろ。コードの可読性が下がる境界線はそこだ。
- 関数のスコープ内: 関数境界を越えて渡すデータ構造であれば、構造（`shape`）かクラスを定義すべきだ。Tupleはあくまで「関数呼び出しの戻り値」のような、一時的なコンテキストでの受け渡しに特化させるのが最も美しい。
最後に
Hackの型システムは、諸君の敵ではない。コードの曖昧さを排除し、バグを未然に防ぐための「最強の防御壁」だ。配列という曖昧な箱にデータを詰め込むのは、もうやめよう。
Tupleを活用し、静的解析が光り輝く、堅牢なコードベースを築き上げてくれ。それが、この言語で開発する者の誇りだ。
コードを書け。そして、型を通せ。それが唯一の近道だ。