なぜGoのジェネリクスはこの形なのか？ - Featherweight Goが明かす設計の核心

Go 1.18でジェネリクスが導入されました。本セッションでは、その仕様、特に「なぜ型制約にinterfaceを使うのか」「なぜコンパイルにモノモーフィゼーションという手法が選ばれたのか」という設計上の選択について、その背景を解説します。
この設計の背景には、Goジェネリクス設計の根幹をなす理論的支柱、Featherweight Goという論文があります。この論文は、Goの父であるRob Pike氏や、Haskellなどで知られる型理論の権威Philip Wadler氏らが参加し、Goのジェネリクスに「理論的な正しさ」を与えるために行われました。この論文で示された理論的な裏付けが、初期案であったcontractsから現在のinterfaceベースの仕様へと繋がりました。
このセッションでは、Featherweight Go論文を基に、Goのジェネリクスの仕組みを深掘りし、以下の点をお話しします。

- interfaceが型制約として採用された経緯（contracts案との比較）
- モノモーフィゼーションの仕組みと、それがもたらす性能上のメリット
- 現在の仕様では実現できない「共変レシーバ」と、それが解決する「式問題」の解説

このセッションを聞くことで、Goのジェネリクスがなぜ現在の仕様になったのかを深く理解し、そのトレードオフを意識した上で、より自信を持ってコードを書けるようになります。

Transcript

1. なぜGoのジェネリクスはこの形なのか？ Featherweight Goが明かす設計の核心 CyberAgent / Qualiarts 鈴木 稜太朗 Go Conference 2025
2. Ryotaro Suzuki •CyberAgent / Qualiarts バックエンドエンジニアとして、運用タイトルの 開発をしている 圏論がとっても好き Go歴は2年くらい Haskellが8年くらい
3. 資料
4. GOとジェネリクス
5. ジェネリクスを求める声 Go Developer Survey 2019 Resultsより https://go.dev/blog/survey2019-results
6. 初期案 型が満たすべき条件を定義する contractsの導入 https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
7. 想定実装
8. 想定実装
9. contractsの撤回 • 新しい概念の追加になるので、大変 • すでに「interface」という型の振る舞いを定義できるものがある interfaceをそのまま型制約に上手く使って実装したい
10. Featherweight Go
11. Featherweight Go Goチームからの依頼で執筆 ジェネリクス設計において根本の設計思想 ジェリックなコードをどのように変換するか定式化
12. Featherweight Java
13. 各研究でのモデル FG：Go言語の主要な機能を抽出した最小限の言語モデル FGG：FGにジェネリクスを追加した言語モデル Featherweight Go FJ：Javaの主要な機能を抽出した最小限の言語モデル FGJ：FJにジェネリクスを追加した言語モデル Featherweight Java
14. Featherweight Goのアプローチ Goチームの要件 
 • 使いやすく理解しやすいこと
 • ランタイムコストが低いこと
 • 可能な限り保守的な拡張であること 
 方針
 • 構造的サブタイピングとジェネリクスの組み合わせ
 • 追加の言語機能なしに型制約を導入
 • モノモーフィゼーションに基づいたコンパイル戦略 

15. FGとFGG
16. FG • チューニング完全な関数型言語としてモデル化 • Goのコンパクトなサブセット Structs Method Interfaces Structural Typing • 型アサーション e.(t)
17. FGモデル
18. FGモデル
19. FGの例
20. FGの課題 EqualにEqを満たした別の型を渡す 実行時にパニック！！ ジェネリクスのない世界での多態の限界 『実行時まで安全かわからない』という問題を 解決するのが FGGの設計
21. FGG • FGのStructs、Methods、Interfacesが型パラメーターを持つ • 型パラメータの制約に Interfacesを使用 • 汎用的な構造に対し、特化した制約を持つ Methodsを定義可能 (共変レ シーバ) • 構造的サブタイピングを維持
22. FGG
23. FGGの例
24. FGGの比較
25. FGGの例（再帰的型制約）
26. FGGの比較
27. FGGモデル
28. まとめ FGの世界
 • 多態性をインターフェースで表現
 • 型の安全性は実行時に型アサーションで保証（プログラマの責任）
 • 常にパニックのリスクが伴う 
 FGGの世界
 • 多態性を型パラメータで表現
 • 型の安全性はコンパイル時に型制約で保証（コンパイラの責任）
 • パニックのリスクをコンパイル時に排除 

29. コンパイル戦略
30. ジェネリクスのコンパイル戦略 FJ
 FGJ
 ジェネリクス
 イレイジャ
 FG
 FGG
 ジェネリクス
 モノモーフィゼーション

31. ジェネリクスのコンパイル戦略 モノモーフィゼーション 
 • 型ごとに使われている部分の専用コードを生成
 • List[string] →（コンパイル）→ string専用のList
 • ランタイムで型アサーションが制限されない 
 • ランタイムオーバーヘッドが低いが、メモリをより食う 
 イレイジャ
 • コンパイル時に型情報を削除
 • List<String> →（コンパイル）→ List
 • ランタイムで型アサーションができない 
 • メモリはあまり食わない 

32. 変換するFGGのコード
33. FGGからFGへの変換
34. FGGからFGへの変換
35. Pairの場合
36. 多相再帰：モノモルフィゼーションできない 全ての型付け可能なFGGがFGに変換できるわけではない

37. ダミーメソッド
38. ダミーメソッド なんのためにダミーメソッドが生成されるのか？

39. ダミーメソッドの例(List)
40. ダミーメソッドの例(List) List<bool>のmapは使用しない

41. ダミーメソッドがない場合 • List[bool]のMapは未使用
 • コンパイラはメソッドを省略し、空のイ ンターフェースを生成
 • 全ての型が空のインターフェースを満 たす
 • コンパイルエラーになるべきlistBool = listIntが可能になり、
 型安全性が崩壊

42. ダミーメソッドの追加
43. Expression Problem（式問題）
44. Expression Problem Eval（評価） String（文字列化） PrettyPrint (整形) Num (数) 実装済み 実装済み 後から追加したい Plus (足し算) 実装済み 実装済み 後から追加したい Mul (掛け算) 後から追加したい 後から追加したい 後から追加したい 行（データ型）と列（操作）のテーブル 関数型言語は列の追加が得意、オブジェクト指向言語は行の追加が得意
45. FGGのアプローチ 「汎用的な構造体定義」と「特化した制約を持つメソッド」の組み合わせ 共変レシーバが、静的な型安全ながら高い拡張性を実現
46. Goと共変レシーバ リリースされた Goのジェネリクスも不変 (invariant) な設計を採用 - 構造体を定義した時点での型制約が、その後のすべてのメソッドで一貫して適用 - Plus[T any]ならメソッドも anyのまま、Plus[T Expr]ならメソッドも Exprのまま 現在のGoで、式問題のような拡張性を実現するには
 • 柔軟性を諦め、静的な安全性を取るか
 • 静的な安全性を諦め、柔軟性を取るか
 • 2つのトレードオフに直面 

47. 柔軟性の低下
48. 型アサーションの復活
49. まとめ
50. まとめ • contractsという新しい概念ではなく、interfaceを土台に変更 • Goチームから多大な感謝が送られた ◦ あなた方の型理論に関する研究のおかげで、我々の理解は絶 大なまでに明確になりました。本当にありがとう！ ◦ 理論と実践が結びついた • 共変レシーバさん...どこ...?
51. ありがとうございました