ジェネリックスを使用すると Go で「*T は型パラメーターへのポインターであり、型パラメーターではありません」というエラーがスローされるのはなぜですか?

item.SetId undefined (type *T is pointer to type parameter, not type parameter)

A does not implement GS (SetId method has pointer receiver)

ジェネリックでGo: 「*T は型パラメーターではなく、型パラメーターへのポインターである」を探索する

gt;

Go の領域プログラミングでは、ジェネリックスを利用する場合、型パラメーターの性質とその制約を理解することが重要です。よくある落とし穴は、型パラメーター自体とその制約を混同することです。

共有 ID フィールドを使用して型 A と B のオブジェクト ストアを実装する例を考えてみましょう。 DRY 原則に従うことを期待して、開発者はジェネリックを使用して、一般的な操作を表す GS インターフェイスを備えたストアを作成します。ただし、GS インターフェイスを使用してオブジェクトを追加し、その ID フィールドを設定しようとすると、コンパイラは次のエラーを生成します。

func Foo[T any, PT interface { SetId(string); *T}](v T) {}

このエラー メッセージを解読すると、型パラメータはその型パラメータとは異なるという基本的な理解につながります。制約。この制約は T に対して許可される操作を確立しますが、

T (T へのポインター) にはいかなる要件も課しません。したがって、T のメソッド セットは、具象型 A で宣言されたポインター レシーバー メソッドを継承せず、*A に適用できるインターフェイスを暗黙的に実装しません。

この問題を解決するには、追加の制約を明示的に定義する必要があります。次の例で示すように、

制約の実装に関するエラーの 2 番目の部分に対処するには、制約を満たすために MyStore を A でインスタンス化する必要があることに注意することが重要です。 SetId() は A ではなく A で定義されています。その後、構造体フィールドの型とメソッド シグネチャを調整してこの変更を反映すると、望ましい動作が可能になります。要約すると、「」を効果的に処理できます。 *T は型パラメーターへのポインターであり、型パラメーターではありません」エラーでは、型パラメーターとその制約を明確に区別する必要があります。これにより、制約が明示的に宣言および実装され、予期しないコンパイラ エラーが防止されます。

以上がジェネリックスを使用すると Go で「*T は型パラメーターへのポインターであり、型パラメーターではありません」というエラーがスローされるのはなぜですか?の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。