Goの型システムには、各コンクリート型が有限で静的に決定可能なメソッドセットを持つ必要があることが求められています。これは、O(1)インターフェースディスパッチを可能にするためです。もし、非ジェネリックレシーバのメソッドが独自の型パラメータを宣言できる場合（例：func (t *MyType) Process[T any](x T)）、その型は理論的には無限のメソッドセットを持つことになり、すべての可能な型引数Tに対して遅延インスタンス化されます。
この設計は、メソッドポインタの固定オフセットに依存するitab（インターフェーステーブル）のレイアウト保証を破壊します。型パラメータを型定義自体に制限することで（例：type MyType[T any] struct{}）、Goは各異なるインスタンス化がコンパイル時に完全で有限のメタデータテーブルを生成することを保証します。これにより、バイナリサイズの予測可能性が保持され、静的ディスパッチを介したインターフェース呼び出しのパフォーマンス特性も維持されます。
高スループットのテレメトリパイプラインを設計している際、私たちのチームは、異なるデータ型（カウンタ、ヒストグラム、ゲージ）を取り込みつつ、コンパイル時の型安全性を維持できる中央集権的なMetricCollectorが必要でした。最初は、collector.Record[T Metric](value T)のようなAPIを望んでおり、ユーザーにコレクタ自体をパラメータ化させずに、MetricCollectorをコンクリート型のままにしておきたかったです。
問題はすぐに明らかになりました：Goはメソッドレベルの型パラメータを拒否し、型消去（anyを格納しキャストする）か、複数のジェネリックインスタンスにコレクタを分割することを強いることになりました。私たちは三つの異なるアプローチを評価しました。
まず、MetricCollectorをジェネリック型MetricCollector[T Metric]に昇格させることを検討しました。これにより、func (mc *MetricCollector[T]) Record(value T)というメソッドを許可します。メリット：完全な型安全性とゼロアロケーションストレージ。デメリット：ユーザーはカウンタとゲージのために別々のコレクタインスタンスを必要とし、インターフェースボクシングなしで混合メトリックを単一のレジストリに集約する能力が失われました。
次に、go:generateを使用して、各メトリックタイプに対してRecordCounter、RecordGaugeなどのモノモーフィズドメソッドを生成するコード生成を探りました。メリット：型安全なメソッドを持つ単一のコレクタインスタンス。デメリット：ビルド時間の複雑さ、ソース管理の膨張、そして新しいメトリックタイプが登場するたびにコードを再生成する必要がありました。
三番目に、パッケージレベルのジェネリック関数func Record[T Metric](c *MetricCollector, value T)に切り替えました。このアプローチは型パラメータをレシーバから切り離しました。メリット：単一のコレクタインスタンスを維持し、関数のコンパイラによるモノモーフィゼーションを通じて型安全性を保持し、インターフェースのオーバーヘッドを回避しました。デメリット：ユーザーにコレクタを明示的な引数として渡すことを求めるため、やや形式的ではない「オブジェクト指向」構文になります。
私たちは、APIの使いやすさとGoのアーキテクチャ的制約のバランスが取れているため、三番目の解決策を選びました。その結果、全ての型の不一致が本番のデプロイメントではなくコンパイル時に捕らえられる、均一なインターフェースを通じて異種メトリックタイプを処理できるコレクタが完成しました。
type Metric interface { Type() string } type MetricCollector struct { storage map[string][]any } // 無効: func (mc *MetricCollector) Record[T Metric](value T) // 有効: 明示的なコレクタ引数を持つジェネリック関数 func Record[T Metric](mc *MetricCollector, value T) { key := value.Type() mc.storage[key] = append(mc.storage[key], value) }
なぜGoはfunc (t *Tree[T]) Insert(x T)のようなメソッドを許可する一方で、func (t *Tree) Insert[T](x T)を拒絶するのか？
レシーバ自体がジェネリックである（Tree[T]）場合、メソッドセットは各特定の型引数に対して具体的にインスタンス化されます（例：Tree[int]にはInsert(x int)メソッドがあります）。メソッドセットは有限のインスタンス化の有限集合に結びついているため、有限のまま維持されます。非ジェネリックレシーバに対してInsert[T]を許可することは、無限の型宇宙によってインデックスが付けられた無限のメソッドファミリーを意味し、実行時メソッド辞書や動的ディスパッチテーブルを必要とし、Goの静的リンクと迅速なインターフェース呼び出しの保証を破ります。
もしコンクリート型がジェネリックメソッドをサポートしたら、インターフェースの満足度はどう壊れるか？
Goにおけるインターフェースの満足度は静的チェックに依存しています：コンパイラは、型がメソッドシグネチャを比較することによってインターフェースを実装していることを確認します。もしMyTypeがMethod[T]()を実装できれば、interface { Methodint }を満たすことはinterface { Methodstring }`とは異なります。コンパイラは無限のvtableのバリエーションを生成する必要があり、満足度チェックを実行時に遅延させることになるため、インターフェース呼び出しが単純なポインタオフセットのルックアップから高コストな動的解決に変わり、言語のパフォーマンスモデルを根本的に変更することになります。
型パラメータは、ジェネリック関数を保持する構造体フィールドを使用してコンクリート型でシミュレートできるか？
はい、しかし重要な意味論上のトレードオフがあります。type Processor struct { handle func[T any](T) }と定義できますが、これはパラメータ化されたメソッドではなく関数の具体的なインスタンスを保存します。あるいは、reflect.Typeからハンドラ関数へのマップを保存することもできます。メリット：実行時の柔軟性。デメリット：コンパイル時の型安全性を失う、リフレクションのオーバーヘッドが発生する、そしてオペレーションを必要とするインターフェースの抽象を破るため、構造体はメソッドセットにメソッドを持たず、フィールドのみを持つことでインターフェースを満たせなくなります。