まとめ:

本テキストでは、開発者が汎用的な concretemethod を直接定義することを可能にする Go の言語仕様の大幅な更新を提案しています。この変更は汎用関数の機能と類似していますが、特定の受容体タイプに対して適用され、既存プロジェクトの改変を必要とせずコード構造に新たな柔軟性を提供します。本提案では、受容体とメソッド名の間にオプションの型パラメータが出現できるようにする構文を導入しており、これは現行コードの完全な後方互換性と、標準的なインターフェースメソッドへの影響の無さを確保しています。

コンクリートメソードがインターフェースとは独立して有用であるという認識を動機として、このシフトは受容体と値の両方に型引数をサポートする更新された文法規則に依存します。そのため、既存のライブラリは即座に機能しますが、コンパイラツールおよび外部解析ツールは、これらの新しい構造を正しく処理するためにパーサおよび型チェッカーを適応させる必要があります。また、リフレクションの制限により、これらの汎用メソッドは標準のリフレクトパッケージを通じて名前またはインデックスでアクセスすることはできませんが、この進化は汎用関数とメソッド定義の間のギャップを埋め込み、より堅牢かつ柔軟なソフトウェアアーキテクチャを可能にする Go のプログラミング能力を強化します。

Go 用のジェネリックメソッド導入の提案と検討

背景と見解の変化

コンクリートメソッド vs インターフェースメソッド
- 本説明では、「リシーバ（自己変数）を持つ関数」をコンクリートメソッドと呼び、インターフェースの構成要素である「インターフェースメソッド」と区別します。
- 歴史的には、メソッドは主にインターフェースを実装する手段として捉えられてきました。そのため、コンクリートメソッドに型パラメータ（ジェネリック）を許容することは、自動的にインターフェースメソッドにも同様の機能を要求するという前提がありました。
- しかし、Go は長い間、そのようなジェネリックなインターフェースメソッドの実装方法が不明確であるため、この機能を提供していませんでした。
なぜコンクリートメソッドをジェネリックにするべきか
- コンクリートメソッドは、インターフェースの実現手段だけでなく、コードの組織化や命名空間へのアクセスという観点からも独立して重要です。
- 構文上の利点もあります。例えば
```
x.a().b()
```
  は自然に読めますが、
```
c(b(a(x)))
```
  のようなネスト表現は直感的ではありません。
- これらの理由から、コンクリートメソッドを単なる「リシーバ付き関数」と捉え直し、その中でジェネリックな機能を付与するという代替案への認識が進んでいます。

提案：構文と機能の変更

メソッド宣言の構文拡張

既存の仕様:

MethodDecl = "func" Receiver MethodName Signature [ FunctionBody ] .

提案される新仕様:
```
MethodDecl = "func" Receiver MethodName [ TypeParameters ] Signature [ FunctionBody ] .
```
- これにより、関数宣言と同様にメソッドも型パラメータ（[TypeParameters]）を受け入れるようになります。
- 型パラメータの作用域は、メソッド名の後から本体の終了時までとされます。

インスタンス化と型引数の処理

呼び出し方:
- 明示的な型指定:
```
obj.m[int](value)
```
- 型の推論:
```
obj.m(value)
```
構文上の調整:
- 現在、
```
T[int]
```
  のような型インスタンス化と
```
a[i]
```
  のようなインデックス式は文法的に区別が困難です。
- これらを識別しやすくするため、型引数の解析位置をプライマリ式（PrimaryExpr）の一部に拡張する変更が必要です。

インターフェースとの互換性

重要: ジェネリックメソッドを持つ型は、その型パラメータを持たないインターフェースメソッドを直接実装することはできません。
- 例:
```
interface { m(string) }
```
  を実装するには、
```
func (T) m(P any)(P)
```
  のようなシグネチャではなく、具体的かつ固定されたシグネチャが必要です。
リフレクション:
- ジェネリック関数と同様、未インスタンス化されたジェネリックメソッドは反射（reflect パッケージ）でアクセスできません。

実装の検討事項

コンパイラと解析器

解析器: 既に型パラメータを受け入れるための構文パースを部分的に行なっており、対応は容易です。
コンパイラバックエンド:
- インターフェース以外のリシーバ経由呼び出しは静的に解決可能ですが、内部的には関数呼び出しへの書き換えが必要になります。
- メソッド式（
```
obj.method
```
  ）もまた、型引数を含む汎用関数の生成に変換されます。

インポート/エクスポートデータ

影響: これが最も破壊的かつ重要な変更です。言語ツールが共有する形式に型パラメータ情報を追加する必要があります。
多くの外部ツールが依存しているため、既存のインフラを壊さないように段階的な移行が必要です。

ツールとライブラリ

既存ライブラリ: 即座の変更は不要ですが、将来この機能を活用できるようになる可能性があります。
言語ツール (go/types など):
- ```
Signature
```
  型などの API 拡張が必要になる見込みです。
- トールのアップデートには少なくとも 1〜2 つのリリースサイクルを要すると予測されます。

まとめと期待効果

後方互換性: 既存のコードとの完全な互換性を保ちつつ、言語機能を拡張します。
将来的な可能性: 現在実装困難だったジェネリックインターフェースメソッドも、コストのかからない解決策が見つかることで将来導入可能になります。
抽象度の向上: より複雑で一般化されたコード（例えば「汎用 Read メソッドを持つ Reader」など）を記述しやすくします。

参照: Go 公式の議論は #49085 と #50981 でなされています。

Go：ジェネリック関数の対応

Japanese Translation: