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

https://gocon.jp/2025/talks/958641/

Transcript

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

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

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

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

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

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

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

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

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

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