generic associated type と Go の判断基準
「ジェネリクスメソッド (Go 1.27) の次に何が来るのか」という問いに対する 2026-08-15 時点の答えは、「一番大きい後続提案がいま落ちようとしている」というものである。
#80448 "spec: generic associated type" は 2026-07-17 に提出された提案で、interface に associated type を持たせようとする。
type Container interface {
type Element any
Add(Element)
At(int) (Element, bool)
}
func First[C Container](c C) (C.Element, bool) { return c.At(0) }
Proposal-FinalCommentPeriod が付いてはいるが、方向は decline に傾いている。
ianlancetaylor は 2026-07-17 のコメントで Go の判断基準そのものを言葉にしている。
Go は型を設計するよりコードを書くことを促してきた言語だ。この提案で、今は簡単に書けないコードが書けるようになるのか? 型をより厳密に制御できるだけなら、Go に合うとは思えない
提案者は ownership / invalid combinations / implementation-dependent results / composition という4つの利点を挙げて応じたが、ianlancetaylor は 2026-07-20 に「4つとも型の設計の話で、コードを書く話ではない」と切り返している。griesemer も 2026-08-12 に同じ方向でコメントしており、「型パラメータで (多少の繰り返しは伴うが) 既に達成できる。得られる利益が薄い割に言語に機構と複雑さを持ち込みすぎる。具体的で説得力のある例が出てこなければ likely decline」としている。
この "write code rather than designing types" という判断基準は、Go の言語提案審査の物差しそのものとして引用しやすい。#77273 "A change of view." が採択されたのは「今は書けないコードが書けるようになる」側の提案だったからであり、generic associated type との対比が効く。同じ「型システムを拡張する」提案でも、コードの書きやすさに直結するかどうかで明暗が分かれている。
併走している他の generics 系提案
generic method とは独立に、LanguageChangeReview で動いている提案がいくつかある。
- #65394 — generic struct のメソッドを型引数の部分集合に限定する提案。
Driver[readonly]にWriteを生やさない、といったユースケースを想定している。open のまま、2026-01-08 に Merovius / jub0bs が再燃させた。 - #44253 — 配列長のジェネリック化。open で 2026-08-12 更新。
archsimdの型爆発 (Uint32x4Uint32x8… の全組み合わせ) が新しい動機として持ち出されている。 - #52654 — インスタンス化せずにジェネリック関数を参照する提案。Merovius が 2023 年に「これが generic methods の主要な障害だと思う」と書いていたが、結果としては generic methods のほうが先に入り、こちらは 2023-07 から放置されたままになっている。メソッド式・メソッド値の扱いについては メソッド式とメソッド値 を参照。
must.Do の却下と同様に、言語機能の提案が通るかどうかは attractive nuisance のような別の判断軸でも決まる。あわせて attractive nuisance を参照。