Go ジェネリクスの共用体制約: 未解決の制限
Go ジェネリックスの領域では、型共用体制約が混乱を引き起こしています。共用体制約内の型に共通のメソッドを使用しようとすると、コンパイラはエラーをスローし、開発者は頭を悩ませます。
次のコードを考えてみましょう。
type A struct {} type B struct {} type AB interface { *A | *B } func (a *A) some() bool { return true } func (b *B) some() bool { return false } func some[T AB](x T) bool { return x.some() } // Compilation error
コンパイラは次のように警告します。 *A と *B の両方が some メソッドを実装しているにもかかわらず、x.some は未定義です。ここで疑問が生じます: 共有メソッドを利用できないのに、なぜ共用体制約を定義するのでしょうか?
Go トラッカーが提案する回避策は、インターフェース制約にメソッドを追加することです:
type AB interface { *A | *B ; some() bool } func some[T AB](x T) bool { return x.some() } // Compiles
しかし、これは不完全な解決策です。 Go の型結合制約では、明示的なインターフェイス宣言を必要とせずに共有メソッドを許可する必要があります。残念ながら、これは Go 1.18 の制限であり、リリース ノートに記載されています:
Go コンパイラーは現在、m が P の制約インターフェイスによって明示的に宣言されている場合に、型パラメーター型 P の値 x に対するメソッド m の呼び出しのみをサポートします。 .
この制限は Go 1.19 で解決される予定です。それまでは、開発者は回避策に頼るか、共有メソッドの統合インターフェイスを定義する必要があります。
以上がGo Generics の Union Constraints で共有メソッドを使用できないのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。