TypeScriptの `void` は「戻り値がないこと」を意味しない：型システムの欺瞞とランタイムの真実
多くの開発者が、TypeScriptの `void` を「値を返さない」という制約だと誤解している。だが、コンパイラAPIの深淵を覗き、V8の実行コンテキストまで遡れば、その理解がいかに甘美な幻想であるかが分かるだろう。
結論から言おう。TypeScriptにおける `void` は、「戻り値を無視する」という意思表示に過ぎない。これは型安全を担保するためのコンパイラ上の防壁であり、ランタイムには一切存在しない概念だ。
1. コンパイラが見ている「void」の正体
TypeScriptにおいて、`void` 型は「その値を呼び出し側で利用してはならない」という静的解析上の制約だ。しかし、コンパイラは出力されたJavaScriptコードに対して、実行時に戻り値を削除するような外科手術は行わない。
以下のコードを見てほしい。
function triggerSideEffect(): void {
return “不吉な文字列”; // コンパイルエラーにはならない
}
const result = triggerSideEffect();
console.log(result); // 実行時: “不吉な文字列” がそのまま出力される
なぜこれが許容されるのか？ それは、TypeScriptが設計された当初、JavaScriptの柔軟な相互運用性を損なわないことが最優先事項だったからだ。特に、高階関数において「戻り値を持つ関数」を「戻り値を期待しない関数」として扱うケース（`Array.prototype.forEach`など）を許容するため、`void` は意図的に「緩い制約」として定義されている。
2. 呼び出し側の「無視」のメカニズム
TypeScript 2.0以降、`strictFunctionTypes` や `strictNullChecks` が標準化されたが、依然として `void` の扱いにはランタイムとの乖離が存在する。
type VoidFunc = () => void;
const f: VoidFunc = () => 42; // エラーにならない
// なぜか？
// TypeScriptは「関数型における戻り値のvoid」を「戻り値を無視する」と解釈する。
// つまり、戻り値がある関数を、戻り値が不要な場所に渡すことは安全であるという理論だ。
この「無視」の挙動は、コールバック関数において顕著になる。イベントループのキューを消費する際、コールバックの戻り値はスタックに積まれるものの、呼び出し側がそれを参照しなければ、JITコンパイラは最適化プロセスの中でその値の生成を排除（デッドコード除去）する可能性がある。
しかし、これは「型安全」とは別次元の話だ。メモリ上のリファレンスが生存し続けるか否かは、あなたの書いたコードがV8のHidden Classにどう解釈されるかに依存する。
3. 「void」の防壁を突破する攻撃ベクトル
セキュリティの観点から言えば、この「型と実行時の乖離」は脆弱性の温床となり得る。特に、戻り値に機密情報を含めてしまい、それが予期せぬ場所で参照されるケースだ。
// 攻撃のトリガーとなり得る設計
function getSensitiveData(): void {
const secret = process.env.SECRET_TOKEN;
return secret; // 意図せずリークする
}
// 呼び出し側が「void関数だから安全だ」と過信している場合
const data = getSensitiveData();
// ここでdataは型上はvoid(実態はstring)となり、ログ出力やデバッグ用フックに混入する可能性がある
4. 厳密な設計のための「プロトコル」
では、我々アーキテクトはどうすべきか。`void` を「単なる無視」として扱うのは、プロの仕事ではない。真に安全なシステムを構築するための指針を提示する。
A. `unknown` との使い分け
戻り値が不要であることを明示したい場合は、型定義を工夫する。`void` を使う場面は「戻り値を利用させない」という強い制約をかけたい時だけだ。もし戻り値の存在が曖昧なら、`unknown` を用いて、呼び出し元に型ガードを強制させるべきだ。
B. ランタイムのガード（ガードレール）
コンパイラを信頼しすぎないこと。特に外部ライブラリをラップする場合、以下の手法でランタイムの挙動を矯正せよ。
function strictVoid
fn(); // 戻り値を破棄する明示的なラッパー
return undefined;
}
C. ESLintの活用
`@typescript-eslint/no-invalid-void-type` や `no-confusing-void-expression` を導入し、静的解析の網をより細かくしろ。言語仕様が「緩い」のであれば、ツールチェーンで「縛る」のがエンジニアの役割だ。
結びに：伝説のアーキテクトからの助言
TypeScriptの型システムは、あなたのコードを「守る」ためのものではなく、「意図を明確化する」ための言語だ。`void` は、その意図が最も曖昧になりやすい場所である。
ランタイムの挙動を想像できないエンジニアは、TypeScriptの型定義をただの「書き込み補助」としてしか捉えられない。だが、型とはコンパイラとあなたの間で行われる契約である。その契約が「無視」を許容しているのか、それとも「禁止」しているのか。その深層を理解した者だけが、堅牢なフロントエンド・アーキテクチャを設計する資格を得る。
さあ、型定義を書き直せ。あなたの書いたその `void` は、本当に「無視」されても安全か？