Go ジェネリック: 無効な複合リテラル

php 編集者 Xigua が最新情報「Go Generics: Invalid Compound Literal」をお届けします。 Go 言語コミュニティでは、ジェネリックは常に大きな関心事のトピックです。 Go 1.18 のリリースにより、ジェネリックが Go 言語の標準ライブラリに正式に含まれるようになります。しかし、この決定は全員に受け入れられたわけではありません。この記事では、読者がこのテクノロジーをより深く理解し、実際の開発でのアプリケーションの参考となるように、Go 言語でのジェネリックスの実装と関連する論争や議論について説明します。

質問内容

次のコードでは「複合リテラル型 t が無効です」というエラーが発生します。

リーリー

インターフェイス thing に thing のみを含める場合、または a string と b int を削除する場合、foo と bar はまったく同じであり、コードはエラーなしで実行されます。しかし、これはジェネリック医薬品の目的に反するのでしょうか?特にどのフィールドにもアクセスできない場合に、このようなジェネリック型をインスタンス化できないのはなぜですか?

https://github.com/golang/go/issues/48522 に関連する可能性があります

回避策

ほとんどのジェネリック型は、複合リテラルとして有効な型ではありません。ただし、ジェネリック型の値を作成する他の方法があるため、それは問題ではありません。

新しいゼロ値へのポインターを作成します:

リーリー

または、ポインタ以外のゼロ値を作成します:

リーリー

なぜこのようにエラーが発生するのかについては、仕様書からの説明を、特定の問題を解決するために修正したものです。

複合リテラルの場合 :

リテラルタイプのコア型 t は、構造体、配列、スライス、またはマップ型である必要があります

コアのタイプとは何ですか?

インターフェイス t は、[...] 単一の型 u が存在する場合、コア型を持ちます。これは、t の型セット内のすべての型の基礎となる型です

他のインターフェイスにはコア タイプはありません。

基礎となるタイプは何ですか?

すべての型 t には基礎となる型があります。t が事前に宣言されたブール型、数値型、文字列型のいずれか、または型リテラルの場合、対応する基礎となる型は t 自体です。それ以外の場合、 t の基になる型は、宣言内で t によって参照される型の基になる型になります。

「型リテラル」は、

struct{int id} などのリテラル構造型を参照できます。したがって、foo と bar の両方の 基礎となる型が struct{int id} である場合、thing core type は struct{int id} であるため、複合リテラルが可能です。 foo と bar が同じ基底型を持たない場合、thing にはコア型がなく、複合リテラルは不可能であるため、エラーが発生します。 正式な定義は複雑に見えるかもしれませんが、結果と実際のポイントは単純です。汎用コードは、可能な型の一般的な動作のみを表現できます。リテラル値は、基礎となる型がすべて同じであるという特殊な場合を除いて、一般的な動作ではありません。

以上がGo ジェネリック: 無効な複合リテラルの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。