Go FAQ が却下した4案
Go FAQ の "Why does Go not support methods with type parameters?" (Go FAQ の該当項目) には、長らくこう書かれていた。
We do not anticipate that Go will ever add generic methods.
直前の一文もあわせて読むと文脈が分かる。「Go permits a generic type to have methods, but, other than the receiver, the arguments to those methods cannot use parameterized types.」つまりレシーバ由来の型パラメータは使えるが、メソッド自身が新しい型パラメータを宣言することは長らく許されていなかった、という前提がある。
その前提には理由がある。Go のジェネリクスはコンパイル時に型ごとの実体を作る仕組みで、実行時に新しい実体を作ることはできない (GC shape stenciling と dictionary)。メソッドに型パラメータを許すなら、一貫性のためにはインターフェース側にも interface{ Nop[T any](T) T } のような宣言を許す必要が出てくる。しかし型がどのインターフェースを実装するかは Go では宣言されない。したがって「どのインスタンス化が実際に呼ばれうるか」を事前に列挙できず、コンパイラは何を用意しておけばよいか分からなくなる。
FAQ はこの問題への対処法として4案を検討し、全部却下した。
- リンク時に足りないメソッド実体を見つけて再コンパイルする — ビルドが遅くなる。しかも「新しい検査が増えて終わらない」例が作れてしまう。
- JIT を入れる — 事前コンパイルの単純さと性能予測性を捨てることになる。
- どんな型にも対応する遅いフォールバックを生成する — 型によって性能が大きく変わり、予測できなくなる。
- ジェネリクスメソッドはインターフェースを満たさない、と定義する — 原文はこうだ。
Define that generic methods cannot be used to satisfy interfaces at all. Interfaces are an essential part of programming in Go. Disallowing generic methods from satisfying interfaces is unacceptable from a design point of view.
FAQ の締めは「None of these choices are good ones, so we chose "none of the above."」というものだった。
ここが伏線になっている。Go 1.27 が実際に採用したのは、この「設計上受け入れがたい」と切り捨てられた4番目の案である (#77273 "A change of view.")。提案 #77273 の1行目は "A change of view." — つまり実装方法が新しく解決されたのではなく、この4番目の案そのものへの評価が反転した、という話になる。実際にジェネリクスメソッドがインターフェースを満たせないという制約は、いまも ジェネリクスメソッドはインターフェースを満たさない としてそのまま Go 1.27 に残っている。
そして、もっと単純な事実として面白いのが、この FAQ の文自体が 2026-08-15 時点でまだ書き換えられていないことだ。Go FAQ の該当項目 を curl で確認したが、"We do not anticipate that Go will ever add generic methods." の一文はそのままだった。FAQ 更新の issue も見当たらない。Go 1.27rc3 でジェネリクスメソッドが実際に動いているのに、公式 FAQ は「入ることはないと思われる」と言い続けている。
詳しくは、この見方の変更がどう起きたかを #77273 "A change of view." に、メソッドという言語機能そのものの捉え方を メソッドはレシーバを持つ関数 に、ジェネリクス全般の背景を ジェネリクスメソッド (Go 1.27) に書いた。
出典
Go Release Party 1.27 の発表資料リポジトリ slide/deck.md (faq / faq-options スライドとスピーカーノート)。同リポジトリ memo.md §1。