CLhttps ： //golang.org/cl/22057はこの問題について言及しています。

https://golang.org/wiki/NoMeTooポリシーをすべての人に先制的に思い出させてください。 絵文字パーティーは上にあります。

さまざまな場所からのディスカッションの概要を提供しようとするGoGenericsディスカッションの概要があります。 また、ジェネリックを使用したい場合に問題を解決する方法の例もいくつか示します。

リンクされた提案には、実装を複雑にし、型の安全性を低下させる可能性のある2つの「要件」があります。

• インスタンス化されるまでわからない型に基づいてジェネリック型を定義します。
• ジェネリック型または関数の定義とその使用の間に明示的な関係を必要としないでください。 つまり、プログラムは、タイプTがジェネリックGを実装していると明示的に言う必要はありません。

これらの要件は、たとえば、ジェネリック型が特性の境界によって制約されるRustの特性システムと同様のシステムを除外しているようです。 なぜこれらが必要なのですか？

C ++ std :: basic_stringのように、ジェネリックスを非常に低いレベルで標準ライブラリに組み込むことは魅力的になります。、std :: allocator>。 これには利点があります（そうでなければ誰もしません）が、理解できないC ++エラーメッセージのように、広範囲で、時には驚くべき効果があります。

C ++の問題は、生成されたコードの型チェックから発生します。 コード生成の前に、追加の型チェックが必要です。 C ++のコンセプト提案は、ジェネリックコードの作成者がジェネリック型の要件を指定できるようにすることで、これを可能にします。 そうすれば、コンパイルはコード生成の前に型チェックに失敗し、単純なエラーメッセージが出力される可能性があります。 C ++ジェネリック（概念なし）の問題は、ジェネリックコードがジェネリック型の仕様であるということです。 それが理解できないエラーメッセージを作成するものです。

ジェネリックコードは、ジェネリック型の仕様であってはなりません。

@tamird非インターフェースタイプTを定義し、後でTがIを実装するようにインターフェースタイプIを定義できることは、Goのインターフェースタイプの重要な機能です。https ：//golang.org/doc/faq#implements_interfaceを参照してください。 Goがジェネリック型を実装し、ジェネリック型Gが「Gの実装に使用できる」と明示的に述べた型Tでのみ使用できる場合は一貫性がありません。

私はRustに精通していませんが、Gを実装するために使用できることを明示的に示すためにTを必要とする言語を知りません。あなたが言及する2つの要件は、GがTに要件を課すことができないという意味ではありません。 Tに要件を課しているので。要件は、GとTを個別に記述できることを意味します。 これはジェネリックスにとって非常に望ましい機能であり、それを放棄することは想像できません。

@ianlancetaylor https://doc.rust-lang.org/book/traits.htmlは、Rustの特性を説明しています。 一般的には良いモデルだと思いますが、現在のGoには不向きです。

@sbunceコンセプトも答えだと思いましたが、最後の提案の前にさまざまな提案に散らばっているアイデアを見ることができます。 しかし、コンセプトが当初C ++ 11になったものについて計画されていたのは残念ですが、現在は2016年であり、まだ物議を醸しており、C ++言語に含まれることに特に近いわけではありません。

アプローチを評価するためのガイダンスとして、学術文献に価値はありますか？

このトピックについて私が読んだ唯一の論文は、開発者はジェネリック型の恩恵を受けていますか？ （ペイウォール申し訳ありませんが、PDFダウンロードへの道をグーグルで検索するかもしれません）

したがって、実験の保守的な解釈
ジェネリック型はトレードオフと見なすことができるということです
肯定的なドキュメントの特徴と
負の拡張特性。 のエキサイティングな部分
研究はそれがの使用が
（より強力な）静的型システムは、
開発時間と同時に期待される利益-
適合–型エラー修正時間の短縮–は表示されませんでした。
そのようなタスクは、将来の実験に役立つと思います
型システムの影響を特定する。

https://github.com/golang/go/issues/15295も、軽量で柔軟なオブジェクト指向ジェネリックを参照していることもわかります。

決定を導くために学界に頼るつもりなら、事前の文献レビューを行う方が良いと思います。そして、実証的研究を証明に依存するものとは異なる方法で評価するかどうかを早期に決定するでしょう。

参照してください：バーバラ・リスコフによるhttp://dl.acm.org/citation.cfm?id=2738008 ：

最新のオブジェクト指向プログラミング言語でのジェネリックプログラミングのサポートは扱いにくく、望ましい表現力が不足しています。 一般的なユースケースで軽量かつシンプルなままで、表現力を追加し、静的チェックを強化する表現力豊かな汎用メカニズムを紹介します。 型クラスや概念と同様に、このメカニズムにより、既存の型で型制約をさかのぼってモデル化できます。 表現力のために、制約を目撃するために明示的に定義および選択できる名前付き構成としてモデルを公開します。 ただし、汎用性の一般的な使用法では、型はプログラマーの追加の作業なしに暗黙的に制約を目撃します。

彼らがそこで行ったことはかなりクールだと思います-これが間違った停止場所である場合は申し訳ありませんが、/ projectsにコメントする場所が見つからず、ここで適切な問題を見つけることができませんでした。

1つ以上の実験的なトランスパイラー（GoジェネリックソースコードからGo 1.xyソースコードコンパイラー）があると面白いかもしれません。
つまり、私の意見に対する話や議論が多すぎて、Goのジェネリックのある種のジェネリックを実装しようとするソースコードを書いている人は誰もいません。

Goとジェネリックスの知識と経験を積むためだけに-何が機能し、何が機能しないかを確認します。
すべてのGoジェネリックソリューションが本当に良くない場合は、; Goのジェネリックはありません。

提案には、バイナリサイズとメモリフットプリントへの影響も含めることができますか？ コンパイラの最適化が機能するように、具体的な値の型ごとにコードの重複があると思います。 具体的なポインタ型のコードが重複しないことを保証したいと思います。

PughDecisionマトリックスを提供します。 私の基準には、目立ちやすさの影響（ソースの複雑さ、サイズ）が含まれます。 また、基準の重みを決定するために、基準を強制的にランク付けしました。 もちろん、あなた自身は変わるかもしれません。 デフォルトの代替手段として「インターフェイス」を使用し、これを「コピー/貼り付け」ジェネリック、テンプレートベースのジェネリック（D言語の動作などを念頭に置いていた）、およびランタイムインスタンス化スタイルのジェネリックと比較しました。 これは非常に単純化されていると確信しています。 それにもかかわらず、それは選択肢を評価する方法についていくつかのアイデアを引き起こすかもしれません...これは私のGoogleスプレッドシートへの公開リンクであるはずです、ここに

@yizhouzhangと@andrewcmyersにpingを送信して、Goのジェネリックのような属について意見を述べることができるようにします。 それは良い一致かもしれないように聞こえます:)

Genus用に考案したジェネリックデザインは、静的なモジュラー型チェックを備えており、型が何らかのインターフェイスを実装することを事前に宣言する必要がなく、妥当なパフォーマンスを備えています。 Goのジェネリックスについて考えているなら、私は間違いなくそれを見ます。 Goについての私の理解からは、それはぴったりのように思えます。

ACMデジタルライブラリへのアクセスを必要としない論文へのリンクは次のとおりです。
http://www.cs.cornell.edu/andru/papers/genus/

Genusのホームページはこちらです： http ：//www.cs.cornell.edu/projects/genus/

コンパイラはまだ公開されていませんが、まもなくリリースされる予定です。

人々が持っているどんな質問にも喜んで答えます。

@mandolyteの決定マトリックスに関して、Genusは17を獲得し、1位になりました。 ただし、スコアにさらにいくつかの基準を追加します。 たとえば、上記で観察された@sbunceなどの他のモジュール式チェックは重要ですが、テンプレートベースのスキームにはそれがありません。 Genusペーパーのテクニカルレポートには、さまざまなジェネリック医薬品の設計を比較した、34ページのはるかに大きな表があります。

Go Genericsの概要ドキュメント全体を確認しました。これは、以前の議論の有益な概要でした。 Genusのジェネリックメカニズムは、私の考えでは、C ++、Java、またはC＃で特定された問題に悩まされていません。 Javaとは異なり、属のジェネリックは洗練されているため、実行時に型を見つけることができます。 プリミティブ型でインスタンス化することもでき、本当に必要のない場所で暗黙のボクシングを行うことはありません。TがプリミティブであるTの配列です。 型システムはHaskellとRustに最も近く、実際にはもう少し強力ですが、直感的でもあると思います。 プリミティブスペシャライゼーションalaC＃は現在、Genusでサポートされていませんが、サポートされている可能性があります。 ほとんどの場合、特殊化はリンク時に決定できるため、真のランタイムコード生成は必要ありません。

CLhttps ： //golang.org/cl/22163はこの問題について言及しています。

新しい言語の概念を追加する必要のないジェネリック型を制約する方法： https：//docs.google.com/document/d/1rX4huWffJ0y1ZjqEpPrDy-kk-m9zWfatgCluGRBQveQ/edit？usp = sharing。

属は本当にクールに見え、それは明らかに芸術の重要な進歩ですが、それがGoにどのように適用されるかはわかりません。 Go型システム/哲学とどのように統合されるかについてのスケッチを持っている人はいますか？

問題は、ゴーチームが妨害の試みであるということです。 タイトルは、ゴーチームの意図を明確に示しています。 そして、それがすべてのテイカーを思いとどまらせるのに十分ではなかった場合、ianによる提案でそのような広いドメインに要求される機能は、ジェネリックが必要な場合、彼らはあなたを望まないことを明確にします。 囲碁チームとの対話を試みることすら不吉です。 ジェネリックスを探している人には、言語を壊すと言います。 新しい旅を始めましょう-多くの人が続きます。 私はすでにフォークで行われたいくつかの素晴らしい仕事を見てきました。 自分を整理し、大義の周りに集結する

Genusの設計に基づいてGoのジェネリック拡張機能を開発したい場合は、喜んでお手伝いします。 既存の言語と調和するデザインを作成するのに十分なほどうまくいくかどうかはわかりません。 最初のステップは、実例を使ったストローマンのデザイン提案だと思います。

@andrewcmyersは、 @ ianlancetaylorがあなたと協力してくれることを望んでいます。 いくつかの例を見るだけで大​​いに役立ちます。

Genusの論文を読みました。 私が理解している限りでは、Javaには適しているように見えますが、Goには自然に適合しているようには見えません。

Goの重要な側面の1つは、Goプログラムを作成するとき、作成する内容のほとんどがコードであるということです。 これは、C ++やJavaとは異なります。C++やJavaでは、作成する内容の多くが型です。 属は主に型に関するもののようです。コードではなく、制約とモデルを記述します。 Goの型システムは非常に単純です。 Genusの型システムははるかに複雑です。

遡及モデリングのアイデアは、Javaには明らかに有用ですが、Goにはまったく適合していないようです。 人々はすでにアダプタタイプを使用して、既存のタイプをインターフェイスに一致させています。 ジェネリックを使用する場合、これ以上何も必要ありません。

これらのアイデアがGoに適用されるのを見るのは興味深いことですが、私は結果について楽観的ではありません。

私はGoの専門家ではありませんが、その型システムは一般的なJavaよりも単純ではないようです。 型の構文は良い意味で少し軽量ですが、根本的な複雑さはほぼ同じように見えます。

Genusでは、制約は型ですが、モデルはコードです。 モデルはアダプターですが、実際のラッピングのレイヤーを追加せずに適応します。 これは、たとえば、オブジェクトの配列全体を新しいインターフェイスに適合させる場合に非常に便利です。 レトロアクティブモデリングを使用すると、配列を目的のインターフェイスを満たすオブジェクトの配列として扱うことができます。

実際に使用する方が簡単ですが、型理論的な意味で（ジェネリック以前の）Javaよりも複雑であっても驚かないでしょう。

比較的複雑なことはさておき、それらは十分に異なっているため、Genusは1：1でマップできませんでした。 大きなサブタイピングはないようです。

興味のある方：

私が言及した関連する哲学的/設計の違いの最も簡単な要約は、次のFAQエントリに含まれています。

• https://golang.org/doc/faq#implements_interface
• https://golang.org/doc/faq#overloading
• https://golang.org/doc/faq#covariant_types
• https://golang.org/doc/faq#variant_types

ほとんどの言語とは異なり、Goの仕様は非常に短く、型システムの関連するプロパティについて明確です。https：//golang.org/ref/spec#Constantsから始まり、「ブロック」というタイトルのセクションまでまっすぐ進みます（すべて印刷された11ページ未満です）。

JavaやC＃ジェネリックとは異なり、Genusジェネリックメカニズムはサブタイピングに基づいていません。 一方、Goにはサブタイピングがありますが、構造的なサブタイピングがあるように思えます。 これは、事前に宣言された関係に依存するのではなく、構造的なフレーバーを持つGenusアプローチにも適しています。

Goに構造的なサブタイピングがあるとは思わない。

したがって、基になるタイプが同一である2つのタイプは同一です。
相互に置き換えることができます、 https：//play.golang.org/p/cT15aQ-PFr

これは、フィールドの共通のサブセットを共有する2つのタイプには拡張されません。
https://play.golang.org/p/KrC9_BDXuh。

2016年4月28日木曜日午後1時9分、Andrew [email protected]
書きました：

JavaやC＃ジェネリックとは異なり、Genusジェネリックメカニズムはに基づいていません
サブタイピング。 一方、Goにはサブタイピングがあるように思えますが、
しかし、構造的なサブタイピング。 これは、Genusアプローチにも適しています。
事前に宣言されたものに頼るのではなく、構造的な味を持っています
関係。

—
このスレッドにサブスクライブしているため、これを受け取っています。
このメールに直接返信するか、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment -215298127

おかげで、私は型がインターフェースを実装するときについていくつかの言語を誤解していました。 実際、私には、適度な拡張機能を備えたGoインターフェースをGenusスタイルの制約として使用できるように見えます。

だからこそ、私はあなたにpingを送信しました。属は、ジェネリックのようなJava / C＃よりもはるかに優れたアプローチのようです。

インターフェイスタイプに特化することに関して、いくつかのアイデアがありました。 たとえば、 _packagetemplates_アプローチ「proposals」 12はその例です。

tl; dr; インターフェイスに特化した汎用パッケージは次のようになります。

package set
type E interface { Equal(other E) bool }
type Set struct { items []E }
func (s *Set) Add(item E) { ... }

バージョン1。パッケージスコープの特殊化：

package main
import items set[[E: *Item]]

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs items.Set
xs.Add(&Item{})

バージョン2。宣言スコープの特殊化：

package main
import set

type Item struct { ... }
func (a *Item) Equal(b *Item) bool { ... }

var xs set.Set[[E: *Item]]
xs.Add(&Item{})

パッケージスコープのジェネリックは、使用が基本的なアルゴリズムとデータ構造に限定されているため、ジェネリックシステムを大幅に悪用することを防ぎます。 それは基本的に、新しい言語抽象化と関数型コードの構築を防ぎます。

宣言スコープの特殊化は、悪用されやすくなり、より冗長になるという犠牲を払って、より多くの可能性があります。 ただし、関数型コードは可能です。例：

type E interface{}
func Reduce(zero E, items []E, fn func(a, b E) E) E { ... }

Reduce[[E: int]](0, []int{1,2,3,4}, func(a, b int)int { return a + b } )
// there are probably ways to have some aliases (or similar) to make it less verbose
alias ReduceInt Reduce[[E: int]]
func ReduceInt Reduce[[E: int]]

インターフェイスの特殊化アプローチには、興味深い特性があります。

• インターフェイスを使用する既存のパッケージは特殊化できます。 たとえば、 sort.Sort[[Interface:MyItems]](...)を呼び出して、インターフェイスではなく具象型で並べ替え作業を行うことができます（インライン化によって得られる可能性があります）。
• テストは単純化されています。一般的なコードがインターフェイスで機能することを確認するだけで済みます。
• それがどのように機能するかを述べるのは簡単です。 つまり、 [[E: int]]がE int $に置き換えると想像してください。

ただし、パッケージ間で作業する場合は、冗長性の問題があります。

type op
import "set"

type E interface{}
func Union(a, b set.Set[[set.E: E]]) set.Set[[set.E: E]] {
    result := set.New[[set.E: E]]()
    ...
}

_もちろん、すべてを実装するよりも述べるのが簡単です。 内部的には、おそらくたくさんの問題とそれがどのように機能するかがあります。_

_PS、ジェネリック医薬品の進歩が遅いことについて不平を言う人たちに、コンパイラ/ランタイムのバグ、SSA、GC、http2など、コミュニティに大きな利益をもたらす問題により多くの時間を費やしてくれたGoチームに拍手を送ります。_

@egonelbreパッケージレベルのジェネリックが「悪用」を防ぐというあなたの指摘は、ほとんどの人が見落としていると思う本当に重要なものです。 これに加えて、それらの相対的なセマンティックおよび構文の単純さ（パッケージおよびインポート構造のみが影響を受ける）により、Goにとって非常に魅力的です。

@andrewcymyersは、GoインターフェースがGenusスタイルの制約として機能すると思うのは興味深いことです。 マルチタイプパラメータの制約を表現できないという問題がまだ残っていると思いました。

ただし、私が気付いたのは、Goではインターフェイスをインラインで記述できることです。 したがって、正しい構文を使用すると、インターフェイスをすべてのパラメーターのスコープに配置し、複数パラメーターの制約をキャプチャできます。

タイプ[V、E]グラフ[Vインターフェイス{Edges（）E}、Eインターフェイス{Endpoints（）（V、V）}] .. ..

制約としてのインターフェースのより大きな問題は、メソッドがJavaほど普及していないことだと思います。 組み込み型にはメソッドがありません。 java.lang.Objectのようなユニバーサルメソッドのセットはありません。 ユーザーは通常、特に必要な場合を除いて、タイプにEqualsやHashCodeなどのメソッドを定義しません。これらのメソッドは、マップキーとして、または等式を必要とするアルゴリズムで使用するためにタイプを修飾しないためです。

（Goでの平等は興味深い話です。特定の要件を満たしている場合、言語はタイプ「==」を提供します（https://golang.org/ref/spec#Logical_operatorsを参照、「comparable」を検索してください）。 == "はマップキーとして機能できます。ただし、タイプが" == "に値しない場合は、マップキーとして機能するように記述できるものはありません。）

メソッドは普及しておらず、組み込み型のプロパティ（操作する演算子など）を簡単に表現する方法がないため、一般的な制約メカニズムとしてコード自体を使用することを提案しました。 上記の4月18日の私のコメントのリンクを参照してください。 この提案には問題がありますが、1つの優れた機能は、ジェネリック数値コードが面倒なメソッド呼び出しの代わりに通常の演算子を使用できることです。

もう1つの方法は、メソッドがない型にメソッドを追加することです。 これは、既存の言語でJavaよりもはるかに軽い方法で実行できます。

タイプIntint
func（i Int）Less（j Int）bool {return i <j}

Int型は、intのすべての演算子とその他のプロパティを「継承」します。 Intとintを一緒に使用するには、2つの間でキャストする必要がありますが、これは面倒な場合があります。

属モデルはここで役立つ可能性があります。 しかし、それらは非常に単純に保つ必要があります。 @ianlancetaylorは、より多くのコード、より少ないタイプを記述しているというGoの特徴づけにおいて狭すぎたと思います。 一般的な原則は、Goは複雑さを嫌うということです。 私たちはJavaとC ++を見て、決してそこに行かないと決心しています。 （違反はありません。）

したがって、モデルのような機能の簡単なアイデアは次のとおりです。ユーザーに上記のIntのような型を記述させ、ジェネリックインスタンス化では「intwith Int」を許可します。つまり、型intを使用しますが、Intのように扱います。 その場合、キーワード、継承セマンティクスなどを備えた、modelと呼ばれる明白な言語構造はありません。 これが実現可能かどうかを知るのに十分なモデルを理解していませんが、それはGoの精神に基づいています。

@jba私たちは確かに複雑さを回避するという原則に同意します。 「可能な限りシンプルですが、それ以上シンプルではありません。」 少なくとも最初は、これらの理由から、いくつかのGenus機能をGoから除外するでしょう。

Genusアプローチの良い点の1つは、組み込み型をスムーズに処理できることです。 Javaのプリミティブ型にはメソッドがなく、Genusはこの動作を継承していることを思い出してください。 代わりに、Genusは、制約を満たすために、プリミティブ型を_あたかも_それらがかなり大きなメソッドスイートを持っているかのように扱います。 ハッシュテーブルでは、そのキーをハッシュして比較できる必要がありますが、すべてのプリミティブ型がこの制約を満たしています。 したがって、Map [int、boolean]のような型のインスタンス化は、これ以上大騒ぎすることなく完全に合法です。 これを実現するために、整数の2つのフレーバー（intとInt）を区別する必要はありません。 ただし、 intが一部の用途に十分な操作を備えていない場合は、上記のIntの使用とほぼ同じモデルを使用します。

言及する価値のあるもう1つのことは、属の「自然モデル」のアイデアです。 通常、汎用型を使用するためにモデルを宣言する必要はありません。type引数が制約を満たしている場合、自然なモデルが自動的に生成されます。 私たちの経験では、これは通常のケースです。 通常、明示的な名前付きモデルを宣言する必要はありません。 ただし、モデルが必要な場合（たとえば、非標準の方法でintをハッシュしたい場合）、構文は提案したものと同様です： Map [int with fancyHash、boolean] 。 Genusは通常のユースケースでは構文的に軽いですが、必要に応じて予備のパワーを備えていると私は主張します。

@egonelbreここで提案しているのは、Scalaでサポートされている仮想型のようです。 Kresten Krab ThorupによるECOOP'97の論文、「仮想型を使用したJavaの汎用性」があり、この方向性を探っています。 また、作業で仮想タイプと仮想クラスのメカニズムを開発しました（「J＆：スケーラブルなソフトウェア構成のためのネストされた交差点」、OOPSLA'06）。

Goではリテラルの初期化が普及しているため、関数リテラルはどのようになるのか疑問に思いました。 これを処理するコードは、主にGoの生成、修正、名前変更に存在するのではないかと思います。たぶん、誰かに刺激を与えるでしょう:-)

//（ジェネリック）func型の定義
タイプSum64func（X、Y）float64 {
float64（X）+ float64（Y）を返します
}

// 1つを位置的にインスタンス化します
i：= 42
var j uint = 86
合計：=＆Sum64 {i、j}

//名前付きパラメータタイプでインスタンス化します
sum：=＆Sum64 {X：int、Y：uint}

//今それを使用します...
結果：= sum（i、j）//結果は128です

イアンの提案はあまりにも多くを要求します。 すべての機能を一度に開発することはできません。何ヶ月もの間、未完成の状態で存在します。

それまでの間、未完成のプロジェクトは、エコシステムを断片化するリスクがあるため、完了するまで公式のGo言語と呼ぶことはできません。

したがって、問題はこれをどのように計画するかです。

また、プロジェクトの大部分は、参照コーパスの開発です。
新しいgo2.0機能を使用しながら、実際のジェネリックコレクション、アルゴリズム、およびその他のものを、それらが慣用的であることに同意するような方法で開発する

可能な構文？

// Module defining generic type
module list(type t)

type node struct {
    next *node
    data t
}

// Module using generic type:
import (
    intlist "module/path/to/list" (int)
    funclist "module/path/to/list" (func (int) int)
)

l := intlist.New()
l.Insert(5)

@ md2perpe 、構文はこの問題の難しい部分ではありません。 実際、これははるかに簡単です。 上記のディスカッションとリンクされたドキュメントを参照してください。

@ md2perpe内部で一般化する方法として、パッケージ全体（「モジュール」）のパラメーター化について説明しました。これは、構文上のオーバーヘッドを削減する方法のようです。 しかし、他にも問題があります。 たとえば、パッケージレベルではないタイプでどのようにパラメータ化するかは明確ではありません。 しかし、そのアイデアはまだ詳細に検討する価値があるかもしれません。

視点を共有したいと思います。パラレルユニバースでは、すべてのGo関数シグネチャは常にインターフェイスタイプのみに言及するように制約されており、今日のジェネリックスの需要の代わりに、インターフェイス値に関連付けられた間接参照を回避する方法があります。 （言語を変更せずに）その問題をどのように解決するかを考えてください。 いくつかのアイデアがあります。

@thwdライブラリの作成者は引き続きインターフェイスを使用しますが、今日必要な型の切り替えと型のアサーションはありません。 そして、ライブラリのユーザーは、ライブラリが型をそのまま使用するかのように具体的な型を渡すだけでしょうか...そしてコンパイラは2つを調整しますか？ そして、それが理由を述べることができなかった場合はどうなりますか？ （ライブラリではモジュロ演算子が使用されていましたが、ユーザーが何かのスライスを提供しました。

私は閉じていますか？ :-)

@mandolyteはい！ このスレッドを汚染しないようにメールを交換しましょう。 「meatthwddotme」で私に連絡できます。 興味があるかもしれないこれを読んでいる他の人; 私にメールを送ってください。あなたをスレッドに追加します。

type systemとcollection libraryの優れた機能です。
考えられる構文：

type Element<T> struct {
    prev, next *Element<T>
    list *List<T>
    value T
}
type List<E> struct {
    root Element<E>
    len int
}

interfaceの場合

type Collection<E> interface {
    Size() int
    Add(e E) bool
}

super typeまたはtype implement ：

func contain(l List<parent E>, e E) bool
<V> func (c Collection<child E>)Map(fn func(e E) V) Collection

上記のJavaでの別名：

boolean contain(List<? super E>, E e)
<V> Collection Map(Function<? extend E, V> mapFunc);

@leaxoy前に述べたように、構文はここでは難しい部分ではありません。 上記の説明を参照してください。

インターフェイスのコストは信じられないほど莫大であることに注意してください。

インターフェースのコストが「信じられないほど」である理由を詳しく説明してください
大きい。
これは、C ++の特殊化されていない仮想呼び出しよりも悪くないはずです。

@minuxパフォーマンスコストについては言えませんが、コード品質に関連しています。 interface{}はコンパイル時に検証できませんが、ジェネリックは検証できます。 私の意見では、これはほとんどの場合、 interface{}を使用する場合のパフォーマンスの問題よりも重要です。

@xoviat

これに必要な処理によってコンパイラーの速度が低下することはないため、これには実際にはマイナス面はありません。

（少なくとも）2つの欠点があります。

1つは、リンカーの作業が増えることです。2つのタイプの特殊化によって、基になるマシンコードが同じになる場合、そのコードの2つのコピーをコンパイルしてリンクする必要はありません。

もう1つは、パラメーター化されたパッケージは、パラメーター化されたメソッドよりも表現力が低いことです。 （詳細については、最初のコメントからリンクされている提案を参照してください。）

ハイパータイプは良い考えですか？

func getAddFunc (aType type) func(aType, aType) aType {
    return func(a, b aType) aType {
        return a+b
    }
}

ハイパータイプは良い考えですか？

ここで説明しているのは、C ++（つまり、テンプレート）のパラメーター化を入力することだけです。 タイプaTypeが指定された情報から+演算を持っていることを知る方法がないため、モジュール方式でタイプチェックしません。 CLU、Haskell、Java、Genusのような制約付き型のパラメーター化がソリューションです。

@ golang101私はそれらの線に沿って詳細な提案をしています。 CLを送信してリストに追加しますが、採用される可能性は低いです。

CLhttps ： //golang.org/cl/38731はこの問題について言及しています。

@andrewcmyers

タイプaTypeが指定された情報から+演算を持っていることを知る方法がないため、モジュール方式でタイプチェックしません。

確かにあります。 その制約は関数の定義に暗黙的に含まれており、その形式の制約は、 getAddFuncのすべての（推移的な）コンパイル時の呼び出し元に伝播できます。

制約はGo_type_の一部ではありません。つまり、言語のランタイム部分の型システムでエンコードすることはできませんが、モジュール方式で評価できないという意味ではありません。

2016-09-compile-time-functions.mdとして私の提案を追加しました。

採用されるとは思いませんが、少なくとも興味深い参考になると思います。

@bcmillsジェネリックスの考慮を除けば、コンパイル時関数は強力なアイデアだと思います。 たとえば、ポップカウントが必要な数独ソルバーを作成しました。 これを高速化するために、さまざまな可能な値のポップカウントを事前に計算し、 Gosourceとして保存しました。 これはgo:generateできることです。 ただし、コンパイル時関数があれば、そのルックアップテーブルはコンパイル時に計算することもでき、マシンで生成されたコードをリポジトリにコミットする必要がなくなります。 一般に、あらゆる種類の記憶可能な数学関数は、コンパイル時関数を使用して事前に作成されたルックアップテーブルに適しています。

より推測的には、たとえば、正規のソースからprotobuf定義をダウンロードし、それを使用してコンパイル時に型を構築することもできます。 しかし、コンパイル時にそれを行うには多すぎるのではないでしょうか。

コンパイル時の関数は、あまりにも強力であると同時に弱すぎるように感じます。柔軟性が高すぎて、奇妙な方法でエラーが発生したり、C ++テンプレートのようにコンパイルが遅くなったりする可能性がありますが、一方で、静的すぎて実行が困難です。第一級関数のようなものに適応します。

2番目の部分では、「特定のタイプのスライスを処理して1つの要素を返す関数のスライス」や、アドホック構文[]func<T>([]T) Tのようなものを作成する方法がわかりません。本質的にすべての静的に型付けされた関数型言語で行うのは非常に簡単です。 本当に必要なのは、ソースコードレベルのコード生成ではなく、パラメトリックタイプをとることができる値です。

@bunsim

2番目の部分では、「特定のタイプのスライスを処理して1つの要素を返す関数のスライス」のようなものを作成する方法がわかりません。

単一のタイプのパラメーターについて話している場合、私の提案では次のように記述されます。

const func SliceOfSelectors(T gotype) gotype { return []func([]T)T (type) }

タイプパラメータと値パラメータの混合について話している場合、いいえ、私の提案ではそれを許可していません。コンパイル時関数のポイントの一部は、ボックス化されていない値を操作できるようにすることと、実行時のパラメトリシティの種類です。あなたが説明しているのは、値のボックス化が必要だと思います。

うん、でも私の意見では、おそらく「ボクシング」を示す特別な構文を使用して、型安全性を維持しながらボクシングを必要とするようなことを許可する必要があります。 「ジェネリック」を追加することの大きな部分は、 interface{}のオーバーヘッドが避けられない場合でも、 interface{}の型の安全性を回避することです。 （おそらく、「すでに」ボックス化されているポインタ型とインターフェイス型を持つ特定のパラメトリック型構造のみを許可しますか？JavaのIntegerなどのボックス化されたオブジェクトは完全に悪い考えではありませんが、値型のスライスは注意が必要です）

コンパイル時の関数は非常にC ++に似ているように感じます。私のような人々にとって、Go2に、記述されたソースコードの操作に基づくハックではなく、サウンド型理論に基づいた最新のパラメトリック型システムがあることを期待している人にとっては非常に残念です。ジェネリックスのない言語で。

@bcmills
あなたが提案するものはモジュール式ではありません。 モジュールAがモジュールBを使用し、モジュールCを使用し、モジュールDを使用する場合、Aの実装者がDを認識していなくても、Dでの型パラメーターの使用方法の変更をAに戻す必要がある場合があります。システム内にあります。 モジュールシステムによって提供される緩い結合は弱くなり、ソフトウェアはより脆弱になります。 これは、C ++テンプレートの問題の1つです。

一方、CLU、ML、Haskell、Genusなどの言語のように、型シグネチャが型パラメータの要件をキャプチャする場合、モジュールは、依存するモジュールの内部にアクセスせずにコンパイルできます。

@bunsim

「ジェネリックス」を追加することの大きな部分は、インターフェース{}のオーバーヘッドが避けられない場合でも、インターフェース{}の型の安全性を回避することです。

「避けられない」は相対的なものです。 ボクシングのオーバーヘッドは、2009年のRussの投稿（https://research.swtch.com/generic）のポイント＃3であることに注意してください。

Go2には、ソースコードの一部を操作することに基づくハックではなく、サウンドタイプ理論に基づいた最新のパラメトリックタイプシステムがあることを期待しています。

優れた「音型理論」は記述的であり、規範的ではありません。 特に私の提案は、（システムFの線に沿った）2次ラムダ計算から引用しています。ここで、 gotypeは種類typeを表し、1次型システム全体が2次型システムに引き上げられます。 -order（ "コンパイル時"）タイプ。

また、CMUでのDavies、Pfenningなどのモーダル型理論の研究にも関連しています。 いくつかの背景として、実行時コード生成のステージング仕様として、ステージングされた計算とモーダルタイプのモーダル分析から始めます。

私の提案の根底にある型理論は、学術文献よりも正式に指定されていないのは事実ですが、それが存在しないという意味ではありません。

@andrewcmyers

モジュールAがモジュールBを使用し、モジュールCを使用し、モジュールDを使用する場合、Aの実装者がDを認識していなくても、Dでの型パラメーターの使用方法の変更をAに戻す必要がある場合があります。システム内にあります。

これは今日のGoでもすでに当てはまります。注意深く見ると、特定のGoパッケージに対してコンパイラーによって生成されたオブジェクトファイルには、エクスポートされたAPIに影響を与える推移的な依存関係の部分に関する情報が含まれていることがわかります。

モジュールシステムによって提供される緩い結合は弱くなり、ソフトウェアはより脆弱になります。

同じ議論がGoAPIで具体的な型ではなくinterface型をエクスポートすることを提唱していたと聞きましたが、その逆がより一般的であることがわかりました。時期尚早の抽象化は型を過剰に制約し、APIの拡張を妨げます。 （そのような例の1つについては、＃19584を参照してください。）この議論の行に依存したい場合は、いくつかの具体的な例を提供する必要があると思います。

これは、C ++テンプレートの問題の1つです。

私が見ているように、C ++テンプレートの主な問題は（順不同で）次のとおりです。

• 過度の構文のあいまいさ。
  a。 タイプ名と値名の間のあいまいさ。
  b。 演算子のオーバーロードに対するサポートが広すぎるため、演算子の使用から制約を推測する機能が弱まります。
• メタプログラミングの過負荷解決への過度の依存（または、同等に、メタプログラミングサポートのアドホックな進化）。
  a。 特にwrt参照-折りたたみルール。
• SFINAEの原則を広範に適用すると、伝播が非常に困難になり、型定義に暗黙の条件が多すぎて、エラーの報告が非常に困難になります。
• AST置換および高次コンパイルアーティファクト（ありがたいことに、少なくとも部分的にモジュールで対処されているようです）の代わりに、トークンの貼り付けとテキストの包含（Cプリプロセッサ）の乱用。
• C ++コンパイラ用の優れたブートストラップ言語が不足しているため、長寿命のコンパイラ系統（GCCツールチェーンなど）でのエラー報告が不十分になります。
• 演算子のセットを（演算子自体を基本的な制約として扱うのではなく）異なる名前の「概念」にマッピングした結果として生じる名前の倍増（場合によっては乗算）。

私は10年前からC ++でコーディングを繰り返しており、C ++の欠点について詳しく説明できてうれしいですが、プログラムの依存関係が推移的であるという事実は、私の苦情リストの一番上にあることはありません。

一方、モジュールAのタイプに単一のメソッドを追加してモジュールDで使用できるようにするためだけに、O（N）依存関係のチェーンを更新する必要がありますか？ それは私を定期的に遅くするような問題です。 パラメトリシティと緩い結合が競合する場合は、いつでもパラメトリシティを選択します。

それでも、メタプログラミングとパラメトリックポリモーフィズムは分離する必要があると確信しており、C ++の混乱が、C ++テンプレートが煩わしい理由の根本的な原因です。 簡単に言えば、C ++は、本質的にステロイドのマクロを使用して型理論のアイデアを実装しようとします。これは、プログラマーがテンプレートを実際のパラメトリック多型と見なし、予期しない動作に見舞われるため、非常に問題があります。 コンパイル時関数は、メタプログラミングとgo generateのハックを置き換えるための優れたアイデアですが、ジェネリックプログラミングを行うための祝福された方法ではないと思います。

「実際の」パラメトリック多型は、結合を緩めるのに役立ち、それと競合してはなりません。 また、他の型システムと緊密に統合する必要があります。 たとえば、インターフェイスタイプの多くの使用法を次のように書き直すことができるように、おそらく現在のインターフェイスシステムに統合する必要があります。

func <T io.Reader> ReadAll(in T)

これにより、インターフェイスのオーバーヘッド（Rustの使用法など）を回避できますが、この場合はあまり役に立ちません。

より良い例はsortパッケージで、次のようなものがあります。

func <T Comparable> Sort(slice []T)

ここで、 Comparableは、型が実装できる古き良きインターフェースです。 Sortは、 Comparableを実装する値型のスライスで、インターフェイス型にボックス化せずに呼び出すことができます。

@bcmills型システムに制約されない推移的な依存関係は、私の見解では、C ++に関するいくつかの不満の核心にあります。 モジュールA、B、C、およびDを制御する場合、推移的な依存関係はそれほど問題にはなりません。一般に、モジュールAを開発しており、モジュールDがそこにあること、および逆にDの開発者を弱く認識しているだけかもしれません。モジュールDが、Dに表示される宣言に変更を加えずに、型パラメーターに対して新しい演算子の使用を開始する場合、または単にその型パラメーターを、独自の新しいモジュールEへの型引数として使用する場合暗黙的な制約-これらの制約は、制約を満たす型引数を使用していない可能性があるすべてのクライアントに浸透します。 開発者Dにそれを吹き飛ばしていることを伝えるものは何もありません。 事実上、デバッグの難しさを伴う、一種のグローバル型推論があります。

Genus [ PLDI'15 ]で採用したアプローチの方がはるかに優れていると思います。 型パラメーターには明示的ですが軽量の制約があります（操作制約のサポートについてあなたの意見を述べます。CLUは1977年にそれを正しく行う方法を示しました）。 属タイプチェックは完全にモジュール化されています。 ジェネリックコードは、コードスペースを最適化するために一度だけコンパイルするか、パフォーマンスを向上させるために特定の型引数に特化することができます。

@andrewcmyers

モジュールDが、Dに表示される宣言に変更を加えずに、型パラメーターで新しい演算子の使用を開始した場合[…] [clients]は、制約を満たす型引数を使用していない可能性があります。 開発者Dにそれを吹き飛ばしていることを伝えるものは何もありません。

もちろんですが、ジェネリックプログラミングメカニズムに関係なく、Goの多くの暗黙の制約についてはすでに当てはまります。

たとえば、関数はインターフェイスタイプのパラメータを受け取り、最初にそのメソッドを順番に呼び出す場合があります。 その関数が後で（追加のゴルーチンを生成することによって）それらのメソッドを同時に呼び出すように変更された場合、「同時使用に対して安全でなければならない」という制約は型システムに反映されません。

同様に、今日のGo型システムは、変数の有効期間に対する制約を指定していませんio.Writerの一部の実装では、渡されたスライスへの参照を保持し、後でそれから読み取ることができると誤って想定しています（たとえば、実際の書き込みを非同期で行うことによって）バックグラウンドのゴルーチンで）、ただし、 Writeの呼び出し元が、後続のWriteで同じバッキングスライスを再利用しようとすると、データ競合が発生します。

または、タイプスイッチを使用する関数がメソッドの異なるパスをとる場合があり、スイッチのタイプの1つに追加されます。

または、エラーを生成する関数がその状態を報告する方法を変更すると、特定のエラーコードをチェックする関数が機能しなくなる可能性があります。 （たとえば、https：//github.com/golang/go/issues/19647を参照してください。）

または、特定のエラータイプをチェックする関数は、エラーのラッパーが追加または削除された場合に機能しなくなる可能性があります（Go 1.5の標準のnetパッケージで発生したように）。

または、APIで公開されているチャネルのバッファリングが変更され、デッドロックや競合が発生する可能性があります。

...等々。

Goは、この点で珍しいことではありません。暗黙の制約は、実際のプログラムではどこにでもあります。

関連するすべての制約を明示的なアノテーションでキャプチャしようとすると、2つの方向のいずれかになります。

一方向では、依存型とアノテーションの複雑で非常に包括的なシステムを構築し、アノテーションは、アノテーションを付けるコードのかなりの部分を要約することになります。 はっきりとわかるように、その方向性はGo言語の他の部分の設計とまったく一致していません。Goは、包括的な静的型付けよりも仕様の単純さとコードの簡潔さを優先します。

他の方向では、明示的なアノテーションは、特定のAPIに関連する制約のサブセットのみをカバーします。 現在、アノテーションは誤った安心感を提供します。暗黙的な制約の変更によりコードが破損する可能性がありますが、明示的な制約が存在すると、開発者は「タイプセーフ」な変更でも互換性が維持されると誤解します。

この種のAPIの安定性を明示的なソースコード注釈によって実現する必要がある理由は私にはわかりません。説明している種類のAPIの安定性は、ソースコードの分析によっても（コードの冗長性を減らして）実現できます。 たとえば、 apiツールでコードを分析し、言語の正式な型システムで表現できるよりもはるかに豊富な制約のセットを出力し、 guruツールに特定のAPI関数、メソッド、またはパラメーターについて、計算された一連の制約を照会する機能。

@bcmillsあなたは善の敵を完璧にしませんか？ はい、型システムでは捉えにくい暗黙の制約があります。 （そして、優れたモジュラー設計は、可能な場合にそのような暗黙の制約を導入することを回避します。）チェックしたいすべてのプロパティを静的にチェックできる包括的な分析があれば素晴らしいでしょう-そしてプログラマーにそれらがどこにあるかについて明確で誤解を招かない説明を提供します間違いを犯しています。 自動エラー診断とローカリゼーションの最近の進歩にもかかわらず、私は息を止めていません。 一つには、分析ツールはあなたが彼らに与えたコードしか分析することができません。 開発者は、自分のコードにリンクする可能性のあるすべてのコードに常にアクセスできるとは限りません。

では、型システムで簡単に把握できる制約がある場合は、プログラマーにそれらを書き留める機能を与えてはどうでしょうか。 静的に制約された型パラメータを使用したプログラミングには40年の経験があります。 これは、効果のあるシンプルで直感的な静的アノテーションです。

ソフトウェアモジュールを階層化するより大きなソフトウェアの構築を開始すると、とにかくそのような暗黙の制約を説明するコメントを書きたいと思うようになります。 それらを表現するための良い、チェック可能な方法があると仮定して、それがあなたを助けることができるように、それからコンパイラを冗談に入れてみませんか？

他の暗黙の制約の例のいくつかには、エラー処理が含まれていることに注意してください。 例外の軽量静的チェック[ PLDI2016 ]は、これらの例に対処すると思います。

@andrewcmyers

では、型システムで簡単に把握できる制約がある場合は、プログラマーにそれらを書き留める機能を与えてはどうでしょうか。
[…]
ソフトウェアモジュールを階層化するより大きなソフトウェアの構築を開始すると、とにかくそのような暗黙の制約を説明するコメントを書きたいと思うようになります。 それらを表現するための良い、チェック可能な方法があると仮定して、それがあなたを助けることができるように、それからコンパイラを冗談に入れてみませんか？

私は実際にこの点に完全に同意し、メモリ管理に関しても同様の議論を頻繁に使用します。 （とにかくデータのエイリアシングと保持に関する不変条件を文書化する必要がある場合は、コンパイル時にそれらの不変条件を強制しませんか？）

しかし、私はその議論をさらに一歩進めます：逆も成り立ちます！ 制約についてコメントを書く必要がない場合（コードを操作する人間にとっては明らかであるため）、コンパイラーに対してそのコメントを書く必要があるのはなぜですか？ 私の個人的な好みに関係なく、Goがガベージコレクションとゼロ値を使用していることは、「プログラマーに明らかな不変条件を述べる必要がない」というバイアスを明確に示しています。 Genusスタイルのモデリングでは、コメントで表現される制約の多くを表現できる場合がありますが、コメントでも省略される制約を排除するという点では、どのようにうまくいくのでしょうか。

Genusスタイルのモデルはとにかく単なるコメント以上のものであるように私には思えます。それらは実際にコードのセマンティクスを変更する場合があり、単にそれを制約するだけではありません。 これで、動作をパラメーター化するための2つの異なるメカニズム（インターフェースとタイプモデル）ができます。 これは、Go言語の大きな変化を表しています。時間の経過とともにインターフェースのベストプラクティスをいくつか発見しました（「コンシューマー側でインターフェースを定義する」など）。その経験が、このような根本的に異なるシステムに変換されるかどうかは明らかではありません。 Go1の互換性を無視します。

さらに、Goの優れた特性の1つは、その仕様を午後に読むことができる（そして大部分が理解できる）ことです。 実質的に複雑にすることなく、Genusスタイルの制約システムをGo言語に追加できるかどうかは私にはわかりません。仕様の変更に関する具体的な提案を見てみたいと思います。

これが「メタプログラミング」の興味深いデータポイントです。 syncおよびatomicパッケージの特定のタイプ（つまり、 atomic.Valueおよびsync.Map ）で、 CompareAndSwapメソッドをサポートすると便利です。しかし、それらはたまたま比較可能なタイプに対してのみ機能します。 残りのatomic.Valueおよびsync.Map APIは、これらのメソッドがなくても引き続き有用であるため、そのユースケースでは、SFINAE（または他の種類の条件付きで定義されたAPI）のようなものが必要であるか、該当する必要があります。タイプのより複雑な階層に戻ります。

先住民の音節を使用するというこの創造的な構文のアイデアを捨てたいと思います。

@bcmillsこれらの3つのポイントについて詳しく説明していただけますか？

1. タイプ名と値名の間のあいまいさ。
2. 演算子のオーバーロードに対する過度に幅広いサポート
   3.メタプログラミングのための過負荷解決への過度の依存

@mahdixもちろんです。

1. タイプ名と値名の間のあいまいさ。

この記事は良い紹介をします。 C ++プログラムを解析するには、どの名前が型で、どの名前が値であるかを知る必要があります。 テンプレート化されたC ++プログラムを解析する場合、テンプレートパラメーターのメンバーが利用できる情報はありません。

複合リテラルのGoでも同様の問題が発生しますが、値と型ではなく、値とフィールド名の間にあいまいさがあります。 このGoコードでは：

const a = someValue
x := T{a: b}

aはリテラルフィールド名ですか、それとも定数aがマップキーまたは配列インデックスとして使用されていますか？

1. 演算子のオーバーロードに対する過度に幅広いサポート

引数に依存するルックアップは、開始するのに適した場所です。 C ++での演算子のオーバーロードは、レシーバータイプのメソッドとして、またはいくつかの名前空間のいずれかでフリー関数として発生する可能性があり、これらのオーバーロードを解決するためのルールは非常に複雑です。

その複雑さを回避する方法はたくさんありますが、（Goが現在行っているように）最も簡単なのは、演算子のオーバーロードを完全に禁止することです。

1. メタプログラミングの過負荷解決への過度の依存

<type_traits>ライブラリは開始するのに適した場所です。 フレンドリーな近所のlibc++の実装をチェックして、過負荷の解決がどのように機能するかを確認してください。

Goがメタプログラミングをサポートしている場合（そしてそれでも非常に疑わしい場合）、条件付き定義を保護するための基本的な操作として、オーバーロードの解決が含まれるとは思いません。

@bcmills
私はC ++を使用したことがないので、事前定義された「インターフェース」の実装による演算子のオーバーロードが複雑さの観点からどこにあるかについて、いくつかの光を当てることができますか。 PythonとKotlinはその一例です。

ADL自体は、ほとんど言及されていないC ++テンプレートの大きな問題だと思います。これは、コンパイラがすべての名前の解決をインスタンス化時間まで遅らせることを余儀なくされ、「理想的」と「怠惰な」コンパイラはここでは異なる動作をし、標準ではそれが許可されています。 演算子のオーバーロードをサポートしているという事実は、実際にはそれの最悪の部分ではありません。

この提案はテンプレートに基づいていますが、マクロ拡張のシステムでは不十分ですか？ 私はgo generateやgotemplateのようなプロジェクトについて話しているのではありません。 私はもっ​​とこのように話している：

macro MacroFoo(stmt ast.Statement) {
    ....
}

マクロは、定型文と反射の使用を減らすことができます。

C ++は、ジェネリックスがテンプレートやマクロに基づくべきではないという十分な例だと思います。 特にGoには、最適化を除いてコンパイル時に実際に「インスタンス化」できない無名関数のようなものがあることを考慮してください。

@samadadiあなたは「あなたの人々の何が悪いのか」と言わずにあなたの主張を理解することができます。 そうは言っても、複雑さの議論はすでに何度も提起されています。

Goは、過去40年間でその機能がますます重要になっているにもかかわらず、パラメトリックポリモーフィズム（ジェネリック）のサポートを省略して単純さを実現しようとする最初の言語ではありません。私の経験では、Goは2学期のプログラミングコースの定番です。

言語にこの機能がない場合の問題は、プログラマーがさらに悪い回避策に頼ってしまうことです。 たとえば、Goプログラマーは、さまざまな目的のタイプの「実際の」コードを生成するためにマクロ拡張されたコードテンプレートを作成することがよくあります。 しかし、実際のプログラミング言語は、コンパイラーが認識する言語ではなく、入力した言語です。 したがって、この戦略は事実上、C ++テンプレートのすべての脆弱性とコード膨張を備えた（もはや標準ではない）言語を使用していることを意味します。

https://blog.golang.org/toward-go2に記載されているように、ニーズと設計の目標を決定できるように、「エクスペリエンスレポート」を提供する必要があります。 数分かけて、観察したマクロの事例を文書化していただけますか？

このバグをトピックと市民に保管してください。 また、 https：//golang.org/wiki/NoMeToo。 追加する独自の建設的な情報がある場合にのみコメントしてください。

@mandolyteジェネリックスの（部分的な）代替としてコード生成を提唱するWeb上で詳細な説明を見つけるのは非常に簡単です：
https://appliedgo.net/generics/
https://www.calhoun.io/using-code-generation-to-survive-without-generics-in-go/
http://blog.ralch.com/tutorial/golang-code-generation-and-generics/

明らかに、このアプローチを採用している人はたくさんいます。

@andrewcmyers 、コード生成を使用する場合、いくつかの制限と便利な警告がありますが。
一般的に、このアプローチが最善/十分であると信じるなら、goツールチェーン内からいくらか類似した世代を許可する努力は祝福だと思います。

• この場合、コンパイラの最適化が課題になる可能性がありますが、実行時間は一貫しており、コードのメンテナンス、ユーザーエクスペリエンス（シンプルさ...）、標準のベストプラクティス、および統一されたコード標準が維持される可能性があります。
  さらに、開発者によって作成されていないコード行を表示するデバッグツール（プロファイラー、ステップデバッガーなど）を除いて、すべてのツールチェーンは同じに保たれますが、デバッグ中にASMコードにステップインするのと少し似ています-のみその読み取り可能なコード:)。

欠点-goツールチェーン内でのこのアプローチの前例（私が知っている）はありません。

要約すると、コード生成をビルドプロセスの一部と見なしてください。複雑すぎず、非常に安全で、実行時に最適化され、言語の単純さとごくわずかな変更を維持できます。

私見：その妥協点は、低価格で簡単に達成できます。

明確にするために、gen、cpp、gofmt -r、または他のマクロ/テンプレートツールで行われるかどうかにかかわらず、マクロスタイルのコード生成は、標準化されている場合でも、ジェネリックの問題に対する優れた解決策であるとは考えていません。 C ++テンプレートと同じ問題があります。コードの膨張、モジュラー型チェックの欠如、デバッグの難しさです。 当然のことながら、他のジェネリックコードの観点からジェネリックコードを構築し始めると、さらに悪化します。 私の考えでは、利点は限られています。Goコンパイラの作成者の生活を比較的シンプルに保ち、効率的なコードを生成します。命令キャッシュのプレッシャーがない限り、最近のソフトウェアでは頻繁に発生します。

ポイントは、コード生成が代わりに使用されるということだったと思います
ジェネリックスなので、ジェネリックスはそれらのユースケースのほとんどを解決しようとする必要があります。

2017年7月26日水曜日、22：41 Andrew Myers、 notifications @ github.comは次のように書いています。

明確にするために、マクロスタイルのコード生成は、実行されたかどうかにかかわらず、考慮しません。
gen、cpp、gofmt -r、またはその他のマクロ/テンプレートツールを使用すると、
標準化されている場合でも、ジェネリック医薬品の問題の解決策。 それは同じです
C ++テンプレートとしての問題：コードの膨張、モジュラー型チェックの欠如、および
デバッグの難しさ。 当然のことながら、構築を開始すると悪化します
他のジェネリックコードの観点からのジェネリックコード。 私の考えでは、利点は
制限付き：Goコンパイラの作成者の生活を比較的シンプルに保つ
命令キャッシュがない限り、効率的なコードを生成します
プレッシャー、現代のソフトウェアで頻繁に発生する状況！

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment-318242016 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AT4HVb2SPMpe5dlEDUQeadIRKPaB74zoks5sR_jSgaJpZM4IG-xv
。

「言語の一部」としてのルックアンドフィールを作成するために言語サポートでラップされたとしても、コード生成が実際のソリューションではないことは間違いありません。

私のポイントは、それが非常に費用対効果が高いということでした。

ところで、コード生成の代替のいくつかを見ると、言語がより優れたツールを提供していれば、それらがはるかに読みやすく、高速であり、いくつかの間違った概念（たとえば、ポインターと値の配列の反復）が欠けていた可能性があることが簡単にわかりますこのため。

そして、おそらくそれは短期的に解決するためのより良い道であり、パッチのようには感じられないでしょう：
「慣用的にも機能する最高のジェネリックスサポート」を考える前に（上記の実装の中には、完全な統合を実現するのに何年もかかると思います）、とにかく必要な「言語で」サポートされる関数のセットを実装します（ビルドインなど）構造ディープコピー）は、これらのコード生成ソリューションをはるかに使いやすくします。

@bcmillsと@ianlancetaylorによるジェネリック医薬品の提案を読んだ後、私は次のことを観察しました。

コンパイル時関数とファーストクラスタイプ

コンパイル時の評価のアイデアは好きですが、純粋関数に限定することのメリットはわかりません。 この提案では、組み込みのgotypeを導入していますが、その使用はconst関数と関数スコープ内で定義されたデータ型に限定されています。 ライブラリユーザーの観点からは、インスタンス化は「新規」などのコンストラクター関数に限定され、次のような関数シグネチャにつながります。

const func New(K, V gotype, hashfn Hashfn(K), eqfn Eqfn(K)) func()*Hashmap(K, V, hashfn, eqfn)

ここでの戻り型は、純粋関数に制限されているため、関数型に分離することはできません。 さらに、シグニチャはシグニチャ自体に2つの新しい「タイプ」（KとV）を定義します。つまり、単一のパラメータを解析するには、パラメータリスト全体を解析する必要があります。 これはコンパイラーにとっては問題ありませんが、パッケージのパブリックAPIが複雑になるのではないかと思います。

Goでパラメータを入力

パラメータ化された型により、ジェネリックプログラミングのほとんどのユースケースが可能になります。たとえば、ジェネリックデータ構造やさまざまなデータ型に対する操作を定義する機能などです。 この提案では、より良いコンパイルエラー、より速いコンパイル時間、およびより小さなバイナリを生成するために必要となるタイプチェッカーの拡張機能を徹底的にリストしています。

「タイプチェッカー」のセクションの下に、提案には、「インデックス可能」、「比較可能」、「呼び出し可能」、「複合」など、プロセスを高速化するためのいくつかの便利なタイプ制限もリストされています...私が理解していないのはユーザーが独自の型制限を指定できるようにしないのはなぜですか？ 提案は次のように述べています

パラメータ化された関数でパラメータ化された型を使用する方法に制限はありません。

ただし、識別子にさらに多くの制約が関連付けられている場合、それはコンパイラーを支援する効果がありませんか？ 検討：

HashMap[Anything,Anything] // Compiler must always compare the implementation and usages to make sure this is valid.

vs

HashMap[Comparable,Anything] // Compiler can first filter out instantiations for incomparable types before running an exhaustive check.

型制約を型パラメーターから分離し、ユーザー定義の制約を許可すると、読みやすさが向上し、汎用パッケージが理解しやすくなります。 興味深いことに、型演繹規則の複雑さに関して提案の最後にリストされている欠陥は、それらの規則がユーザーによって明示的に定義されている場合、実際に軽減することができます。

@ smasher164

コンパイル時の評価のアイデアは好きですが、純粋関数に限定することのメリットはわかりません。

利点は、個別のコンパイルが可能になることです。 コンパイル時関数がグローバル状態を変更できる場合、コンパイラーはその状態を使用可能にするか、リンカーがリンク時にそれらをシーケンスできるように編集をジャーナル化する必要があります。 コンパイル時関数がローカル状態を変更できる場合、どの状態がローカルかグローバルかを追跡する方法が必要になります。 どちらも複雑さを増し、どちらかがそれを相殺するのに十分な利益を提供するかどうかは明らかではありません。

@ smasher164

私が理解していないのは、なぜユーザーが独自のタイプ制限を指定できるようにしないのですか？

その提案の型制限は、言語の構文の操作に対応しています。 これにより、新機能の表面積が減少します。構文上の制約はすべて使用法から推測できるため、型を制約するために追加の構文を指定する必要はありません。

識別子にさらに多くの制約が関連付けられている場合、それはコンパイラーを支援する効果がありませんか？

言語は、コンパイラー作成者ではなく、ユーザー向けに設計する必要があります。

すべての構文上の制約は使用法から推測できるため、型を制約するために追加の構文を指定する必要はありません。

これは、C ++がたどったルートです。 関連する使用法を特定するには、グローバルなプログラム分析が必要です。 プログラマーはコードをモジュール方式で推論することはできず、エラーメッセージは冗長で理解できません。

必要な操作を指定するのはとても簡単で軽量です。 例については、CLU（1977）を参照してください。

@andrewcmyers

関連する使用法を特定するには、グローバルなプログラム分析が必要です。 プログラマーがコードをモジュール方式で推論することはできません。

それは「モジュラー」の特定の定義を使用していますが、これはあなたが想定しているほど普遍的ではないと思います。 2013年の提案では、各関数またはタイプには、インポートされたパッケージからボトムアップで推測される明確な一連の制約があります。これは、非パラメトリック関数の実行時（および実行時の制約）がボトムアップで導出されるのとまったく同じ方法です。今日のコールチェーンからアップ。

おそらく、 guruまたは同様のツールを使用して推測された制約をクエリし、エクスポートされたパッケージメタデータからのローカル情報を使用してそれらのクエリに答えることができます。

エラーメッセージは冗長で理解できないものです。

単純に生成されたエラーメッセージが理解できないことを示すいくつかの例（GCCとMSVC）があります。 暗黙の制約のエラーメッセージが本質的に悪いと仮定するのは簡単ではないと思います。

推論された制約の最大の欠点は、型を完全に理解していなくても、制約を導入する方法で型を簡単に使用できることだと思います。 最良の場合、これはユーザーが予期しないコンパイル時の失敗に遭遇する可能性があることを意味しますが、最悪の場合、これは誤って新しい制約を導入することによってコンシューマーのパッケージを壊す可能性があることを意味します。 明示的に指定された制約はこれを回避します。

また、インターフェイスは表現度に制限がありますが、明示的なランタイムタイプの制約であるため、明示的な制約が既存のGoアプローチと一致していないと個人的には感じません。

単純に生成されたエラーメッセージが理解できないことを示すいくつかの例（GCCとMSVC）があります。 暗黙の制約のエラーメッセージが本質的に悪いと仮定するのは簡単ではないと思います。

非ローカル型推論（提案するもの）が不正なエラーメッセージを生成するコンパイラのリストは、それよりもかなり長くなります。 これには、SML、OCaml、およびGHCが含まれ、エラーメッセージの改善に多くの努力が払われており、少なくともいくつかの明示的なモジュール構造が役立ちます。 あなたはもっとうまくやれるかもしれません、そしてあなたがあなたが提案するスキームで良いエラーメッセージのためのアルゴリズムを思いついたなら、あなたは素晴らしい出版物を持っているでしょう。 そのアルゴリズムの出発点として、エラーのローカリゼーションに関するPOPL2014およびPLDI2015の論文が役立つ場合があります。 彼らは多かれ少なかれ最先端です。

構文上の制約はすべて、使用法から推測できるためです。

それは型チェック可能なジェネリックプログラムの幅を制限しませんか？ たとえば、type-paramsプロポーザルは「Iterable」制約を指定していないことに注意してください。 現在の言語では、これはスライスまたはチャネルのいずれかに対応しますが、複合型（リンクリストなど）は必ずしもこれらの要件を満たしているとは限りません。 次のようなインターフェイスの定義

type Iterable[T] interface {
    Next() T
}

リンクリストの場合に役立ちますが、このインターフェイスを満たすには、組み込みのスライスタイプとチャネルタイプを拡張する必要があります。

「Iterables、slices、またはchannelsのいずれかであるすべてのタイプのセットを受け入れる」という制約は、ユーザー、パッケージ作成者、およびコンパイラーの実装者にとって、お互いに有利な状況のように見えます。 私が言いたいのは、制約は構文的に有効なプログラムのスーパーセットであり、言語の観点からは意味がなく、APIの観点からのみ意味があるものもあるということです。

言語は、コンパイラー作成者ではなく、ユーザー向けに設計する必要があります。

同意しますが、別の言い方をすればよかったのかもしれません。 コンパイラ効率の向上は、ユーザー定義の制約の副作用である可能性があります。 とにかく、ユーザーはコンパイラーよりもAPIの動作をよく理解しているため、主な利点は読みやすさです。 ここでのトレードオフは、一般的なプログラムは、受け入れるものについてもう少し明確にする必要があるということです。

代わりに

type Iterable[T] interface {
    Next() T
}

「インターフェース」の概念を「制約」から分離しました。 その後、私たちは持っているかもしれません

type T generic

type Iterable class {
    Next() T
}

ここで、「クラス」は、Javaスタイルのクラスではなく、Haskellスタイルのタイプクラスを意味します。

「インターフェース」とは別に「型クラス」を使用すると、2つのアイデアの非直交性の一部を明らかにするのに役立つ場合があります。 その場合、 Sortable （sort.Interfaceを無視）は次のようになります。

type T generic

type Comparable class {
    Less(a, b T) bool
}

type Sortable class {
    Next() Comparable
}

@andrewcmyersによるGenusの「型クラスと概念」セクションへのフィードバックとGoへの適用性を以下に示します。

このセクションでは、型クラスと概念の制限について説明します。

まず、制約の満足度を一意に目撃する必要があります

この制限を理解しているかどうかはわかりません。 識別子を分離するために制約を結び付けると、特定のタイプに一意になるのを防ぐことができませんか？ Genusの「where」句は基本的に特定の制約から型/制約を構築しているように見えますが、これは特定の型から変数をインスタンス化することに類似しているようです。 この方法での制約は、種類に似ています。

Goに適合した、制約定義の劇的な簡略化を次に示します。

kind Any interface{} // accepts any type that satisfies interface{}.
type T Any // Declare a type of Any kind. Also binds it to an identifier.
kind Eq T == T // accepts any type for which equality is defined.

したがって、マップ宣言は次のように表示されます。

type Map[K Eq, V Any] struct {
}

Genusでは、次のようになります。

type Map[K, V] where Eq[K], Any[V] struct {
}

また、既存のType-Params提案では、次のようになります。

type Map[K,V] struct {
}

制約が既存の型システムを活用できるようにすることで、言語の機能間の重複を取り除き、新しい機能を理解しやすくすることができるということには、誰もが同意できると思います。

第二に、それらのモデルは単一のタイプを適応させる方法を定義しますが、サブタイピングのある言語では、一般に、適応された各タイプはそのすべてのサブタイプを表します。

この言語には、名前付き/名前なしの型と重複するインターフェースの間の適切な変換ルールがすでにあるため、この制限はGoにはあまり関係がないようです。

与えられた例は、ソリューションとしてモデルを提案しています。これは、Goにとっては便利ですが、必須ではない機能のようです。 たとえば、ライブラリがhttp.Handlerを実装する型を期待していて、ユーザーがコンテキストに応じて異なる動作を望んでいる場合、アダプターの作成は簡単です。

type handleFunc func(http.ResponseWriter, *http.Request)
func (f handlerFunc) ServeHTTP(w http.ResponseWriter, r *http.Request) { f(w,r) }

実際、これは標準ライブラリが行うことです。

@ smasher164

まず、制約の満足度を一意に目撃する必要があります
この制限を理解しているかどうかはわかりません。 識別子を分離するために制約を結び付けると、特定のタイプに一意になるのを防ぐことができませんか？

アイデアは、Haskellとは異なり、Genusでは同じタイプの同じ制約を複数の方法で満たすことができるということです。 たとえば、 HashSet[T]がある場合、通常の方法で文字列をハッシュするためにHashSet[String]を記述できますが、文字列をハッシュしてCaseInsensと比較するためにHashSet[String with CaseInsens]を記述できます。モデル。おそらく大文字と小文字を区別しない方法で文字列を処理します。 Genusは、実際にはこれら2つのタイプを区別します。 これはGoにとってやり過ぎかもしれません。 型システムがそれを追跡しない場合でも、型によって提供されるデフォルトの操作をオーバーライドできることが重要であるように思われます。

kind Any interface {} // interface {}を満たす任意のタイプを受け入れます。
type T Any //任意の種類の型を宣言します。 また、それを識別子にバインドします。
kind Eq T == T //等式が定義されているすべての型を受け入れます。
タイプMap [K Eq、V Any] struct {.. ..
}

属におけるこれの道徳的同等物は次のようになります：

constraint Any[T] {}
// Just use Any as if it were a type
constraint Eq[K] {
   boolean equals(K);
}
class Map[K, V] where Eq[K] { ... }

ファミリアでは、単に次のように記述します。

interface Eq {
    boolean equals(This);
}
class Map[K where Eq, V] { ... }

編集：＃4146で説明されているように、リフレクトベースのソリューションを優先してこれを撤回します。以下で説明するジェネリックベースのソリューションは、構成の数が直線的に増加します。 リフレクトベースのソリューションには常にパフォーマンスのハンディキャップがありますが、実行時にそれ自体を最適化できるため、コンポジションの数に関係なくハンディキャップが一定になります。

これは提案ではありませんが、提案を設計するときに考慮すべき潜在的なユースケースです。

今日のGoコードでは2つのことが一般的です

• 追加機能を提供するためのインターフェース値のラッピング（フレームワークの場合はhttp.ResponseWriterのラッピング）
• インターフェース値が時々持つオプションのメソッドを持っている（ net.Error Temporary() boolのように）

これらは両方とも優れていて便利ですが、混ざり合うことはありません。 インターフェイスをラップすると、ラッピングタイプで定義されていないメソッドにアクセスできなくなります。 つまり、与えられた

type MyError struct {
  error
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.error)
}

その構造体でエラーをラップすると、元のエラーの追加メソッドが非表示になります。

エラーを構造体でラップしないと、追加のコンテキストを提供できません。

受け入れられた一般的な提案では、次のようなものを定義できるとしましょう（私が意図的に醜くしようとした任意の構文なので、誰もそれに集中しません）

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.E)
}

埋め込みを活用することで、エラーインターフェイスを満たす任意の具象型を埋め込み、それをラップして他のメソッドにアクセスすることができます。 残念ながら、これは私たちを途中までしか到達させません。

ここで本当に必要なのは、エラーインターフェイスの任意の値を取得し、その動的型を埋め込むことです。

これはすぐに2つの懸念を引き起こします

• タイプは実行時に作成する必要があります（とにかくreflectによって必要になる可能性があります）
• エラー値がnilの場合、タイプの作成はパニックになります。

それらがあなたの考えに悩まされていない場合は、ジェネリックパラメータのリストに「常に動的タイプのインターフェイス値をインスタンス化する」という注釈を付けることによって、インターフェイスを動的タイプに「飛躍」させるメカニズムも必要です。 "または、型のインスタンス化中にのみ呼び出すことができるいくつかの魔法の関数によって、インターフェイスのボックスを解除して、その型と値を正しくスプライスできるようにします。

それがなければ、インターフェイスの動的タイプではなく、エラータイプ自体でMyErrorをインスタンス化するだけです。

情報を引き出して（どういうわけか）適用するための魔法のunbox関数があるとしましょう：

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  return MyError{
    E: unbox(err),
    extraContext: ec,
  }
}

ここで、動的型が*net.DNSErrorである非nilエラーerrがあるとします。 次にこれ

wrapped := wrap(getExtraContext(), err)
//wrapped 's dynamic type is a MyStruct embedding E=*net.DNSError
_, ok := wrapped.(net.Error)
fmt.Println(ok)

trueします。 しかし、 err *os.PathErrorだった場合、falseが出力されます。

デモンストレーションで使用されている鈍い構文を考えると、提案されたセマンティクスが明確であることを願っています。

また、より少ないメカニズムとセレモニーでその問題を解決するためのより良い方法があることを願っていますが、上記はうまくいくと思います。

@jimmyfrasche私があなたが何を望んでいるかを理解しているなら、それはラッパーのない適応メカニズムです。 元のオブジェクトを非表示にする別のオブジェクトでラップせずに、タイプが提供する一連の操作を拡張できるようにする必要があります。 これは、Genusが提供する機能です。

@andrewcmyersいいえ。

GoのStructは埋め込みを許可します。 名前はないが構造体に型があるフィールドを追加すると、2つのことが行われます。型と同じ名前のフィールドが作成され、その型のメソッドへの透過的なディスパッチが可能になります。 それは継承のようにひどく聞こえますが、そうではありません。 メソッドFoo（）を持つタイプTがある場合、以下は同等です

type S struct {
  T
}

と

type S struct {
  T T
}
func (s S) Foo() {
  s.T.Foo()
}

（Fooが呼ばれるとき、その「これ」は常にタイプTです）。

構造体にインターフェースを埋め込むこともできます。 これにより、構造体にインターフェイスのコントラクト内のすべてのメソッドが与えられます（ただし、暗黙のフィールドに動的な値を割り当てる必要があります。そうしないと、nullポインタ例外と同等のパニックが発生します）

Goには、型のメソッドに関してコントラクトを定義するインターフェースがあります。 コントラクトを満たす任意のタイプの値は、そのインターフェースの値にボックス化できます。 インターフェイスの値は、内部型マニフェスト（動的型）へのポインターであり、その動的型の値（動的値）へのポインターです。 インターフェイス値に対してタイプアサーションを実行して、（a）非インターフェイスタイプにアサートする場合は動的値を取得し、（b）動的値も満たす別のインターフェイスにアサートする場合は新しいインターフェイス値を取得できます。 後者を使用してオブジェクトを「機能テスト」し、オプションのメソッドをサポートしているかどうかを確認するのが一般的です。 前の例を再利用するために、いくつかのエラーには「Temporary（）bool」メソッドがあり、エラーが一時的なものであるかどうかを確認できます。

func isTemp(err error) bool {
  if t, ok := err.(interface{ Temporary() bool}); ok {
    return t.Temporary()
  }
  return false
}

追加の機能を提供するために、あるタイプを別のタイプでラップすることも一般的です。 これは、非インターフェースタイプでうまく機能します。 インターフェイスをラップすると、それについて知らないメソッドも非表示になり、「機能テスト」タイプのアサーションでそれらを回復することはできません。ラップされたタイプは、オプションのメソッドがある場合でも、インターフェイスの必要なメソッドのみを公開します。 。 検討：

type A struct {}
func (A) Foo()
func (A) Bar()

type I interface {
  Foo()
}

type B struct {
  I
}

var i I = B{A{}}

iでBarを呼び出すことはできません。また、iの動的型がBであることがわかっていない限り、それが存在することを知ることもできません。 。

これにより、特にエラーやリーダーなどの一般的なインターフェイスを処理する場合に、実際の問題が発生します。

動的な型と値をインターフェイスから（安全で制御された方法で）持ち上げる方法がある場合は、それを使用して新しい型をパラメーター化し、埋め込みフィールドを値に設定して、新しいインターフェイスを返すことができます。 次に、元のインターフェイスを満たし、追加したい拡張機能を備えた値を取得しますが、元の動的タイプの残りのメソッドは、機能テストが必要です。

@jimmyfrasche確かに。 Genusでできることは、1つのタイプを使用して、ボックス化せずに「インターフェイス」コントラクトを満たすことです。 値には、元のタイプと元の操作がまだあります。 さらに、プログラムは、タイプがコントラクトを満たすために使用する操作を指定できます。デフォルトでは、これらはタイプが提供する操作ですが、タイプに必要な操作がない場合、プログラムは新しい操作を提供できます。 また、タイプが使用する操作を置き換えることもできます。

@jimmyfrasche @andrewcmyersそのユースケースについては、 https： //github.com/golang/go/issues/4146#issuecomment-318200547も参照してください。

@jimmyfrasche私には、ここでの重要な問題は変数の動的な型/値を取得することのように思えます。 埋め込みは別として、簡単な例は次のようになります。

type MyError generic_over[E which_is_a_type_satisfying error] struct {
  e E
  extraContext extraContextType
}
func (m MyError) Error() string {
  return fmt.Sprintf("%s: %s", m.extraContext, m.e)
}

eに割り当てられる値は、 errorを実装する$ *net.DNSErrorのような動的（または具象）タイプである必要があります。 将来の言語変更がこの問題に取り組む可能性のあるいくつかの可能な方法を次に示します。

1. 変数の動的な値を明らかにする魔法のunboxのような関数があります。 これは、ユニオンなど、具体的でないすべてのタイプに適用されます。
2. 言語変更が型変数をサポートしている場合は、変数の動的型を取得する手段を提供します。 タイプ情報を使用して、 unbox関数を自分で作成できます。 例えば、

func unbox(v T1) T2 {
    t := dynTypeOf(v)
    return v.(t)
}

wrapは、以前と同じ方法で、または次のように書くことができます

func wrap(ec extraContext, err error) error {
  if err == nil {
    return nil
  }
  t := dynTypeOf(err)
  return MyError{
    e: v.(t),
    extraContext: ec,
  }
}

1. 言語の変更が型の制約をサポートしている場合、別のアイデアがあります。

type E1 which_is_a_type_satisfying error
type E2 which_is_a_type_satisfying error

func wrap(ec extraContext, err E1) E2 {
  if err == nil {
    return nil
  }
  return MyError{
    e: err,
    extraContext: ec,
  }
}

この例では、エラーを実装する任意のタイプの値を受け入れます。 error wrapのユーザーは、1つ受け取ります。 ただし、 MyError eの型は、渡されるerrの型と同じであり、インターフェイスの型に限定されません。 2と同じ動作が必要な場合。

var iface error = ...
wrap(getExtraContext(), unbox(iface))

他の誰もそれをしていないように思われるので、 https：//blog.golang.org/toward-go2によって要求されたジェネリックの非常に明白な「経験報告」を指摘したいと思います。

1つ目は、組み込みのmapタイプです。

m := make(map[string]string)

次は、組み込みのchanタイプです。

c := make(chan bool)

最後に、標準ライブラリには、ジェネリックスがより安全に機能するinterface{}の選択肢がたくさんあります。

• heap.Interface （https://golang.org/pkg/container/heap/#Interface）
• list.Element （https://golang.org/pkg/container/list/#Element）
• ring.Ring （https://golang.org/pkg/container/ring/#Ring）
• sync.Pool （https://golang.org/pkg/sync/#Pool）
• 今後のsync.Map （https://tip.golang.org/pkg/sync/#Map）
• atomic.Value （https://golang.org/pkg/sync/atomic/#Value）

私が行方不明になっている他の人がいるかもしれません。 重要なのは、上記のそれぞれがジェネリックスが役立つと私が期待するところです。

（注： sort.Sortは、ジェネリックの代わりにインターフェイスを使用する方法の優れた例であるため、ここには含めません。）

http://www.yinwang.org/blog-cn/2014/04/18/golang
ジェネリックは重要だと思います。そうでないと、同様のタイプを処理できません。インターフェイスで問題を解決できない場合があります。

単純な構文と型システムは、Goの重要な長所です。 ジェネリックスを追加すると、言語はScalaやHaskellのような醜い混乱になります。 また、この機能は疑似学術ファンを魅了し、最終的にはコミュニティの価値観を「これを成し遂げよう」から「CS理論と数学について話そう」に変換します。 ジェネリックを避けてください、それは深淵への道です。

@bxqgitはこの市民を守ってください。 誰かを侮辱する必要はありません。

将来がどうなるかはわかりますが、98％の時間はジェネリック医薬品は必要ありませんが、ジェネリック医薬品が必要になったときはいつでも使用できればと思います。 それらがどのように使用されているのか、どのように誤って使用されているのかは別の議論です。 ユーザーの教育はプロセスの一部である必要があります。

@bxqgit
ジェネリックデータ構造（ツリー、スタック、キューなど）やジェネリック関数（マップ、フィルター、リデュースなど）などのジェネリックが必要な状況があり、これらは避けられず、ジェネリックの代わりにインターフェイスを使用します。これらの状況は、コードライターとコードリーダーの両方に非常に複雑なものを追加するだけでなく、実行時のコード効率にも悪影響を与えるため、インターフェイスを使用して複雑な書き込みを反映するよりも、ジェネリック言語に追加する方がはるかに合理的です。と非効率的なコード。

@bxqgitジェネリックスを追加しても、必ずしも言語が複雑になるわけではありません。これは、単純な構文でも実現できます。 ジェネリックスでは、 @ riwogoが言ったように、データ構造で非常に役立つ可変コンパイル時型制約を追加しています。

現在のインターフェースシステムは非常に便利ですが、たとえば、リストの一般的な実装が必要な場合は非常に悪いです。これは、インターフェースでは実行時の型の制約が必要ですが、ジェネリックを追加すると、ジェネリック型を次のように置き換えることができます。コンパイル時は実際の型であるため、制約は不要です。

また、背後にいる人々は、あなたが「CS理論と数学」と呼ぶものを使用して言語を開発し、「これを成し遂げている」人々でもあることを忘れないでください。

また、背後にいる人々は、あなたが「CS理論と数学」と呼ぶものを使用して言語を開発し、「これを成し遂げている」人々でもあることを忘れないでください。

個人的には、Go言語の設計ではCS理論や数学はあまり見かけません。 それはかなり原始的な言語であり、私の意見では良いです。 また、あなたが話している人々は、ジェネリックを避けて物事を成し遂げることに決めました。 それがうまく機能する場合、なぜ何かを変更するのですか？ 一般的に、言語の構文を絶えず進化させ、拡張することは悪い習慣だと思います。 それはHaskellとScalaの混乱につながる複雑さを追加するだけです。

テンプレートは複雑ですが、ジェネリックは単純です

sortパッケージの関数SortInts、SortFloats、SortStringsを見てください。 またはSearchInts、SearchFloats、SearchStrings。 または、パッケージio / ioutilのbyNameのLen、Less、およびSwapメソッド。 純粋な定型コピー。

コピーおよび追加機能は、スライスをはるかに便利にするために存在します。 ジェネリックは、これらの機能が不要であることを意味します。 ジェネリックスは、ユーザーが作成したデータ型は言うまでもなく、マップとチャネルに対して同様の関数を作成することを可能にします。 確かに、スライスは最も重要な複合データ型であり、そのためこれらの関数が必要でしたが、他のデータ型は依然として有用です。

私の投票は、一般化されたアプリケーションジェネリックに反対し、複数の基本タイプで機能するappendやcopyなどのより組み込みのジェネリック関数に賛成です。 おそらくsortとsearchをコレクションタイプに追加できますか？

私のアプリケーションでは、欠落している唯一の型は順序付けられていないセット（https://github.com/golang/go/issues/7088）です。これを組み込み型として使用して、 sliceのようなジェネリック型を取得します。 map 。 作業をコンパイラーに入れ（各基本タイプと選択したstructタイプのセットのベンチマークを行い、最高のパフォーマンスが得られるように調整します）、アプリケーションコードに追加の注釈を付けないようにします。

$＃$ sync.Map smapが組み込まれています。 ランタイムタイプの安全性にinterface{}を使用した私の経験から、設計上の欠陥があります。 コンパイル時の型チェックは、Goを使用する主な理由です。

@pciet

ランタイムタイプの安全性のためにinterface {}を使用した私の経験から、設計上の欠陥があります。

小さな（タイプセーフな）ラッパーを作成できますか？
https://play.golang.org/p/tG6hd-j5yx

@pierrreそのラッパーはreflect.TypeOf(item).AssignableTo(type)チェックよりも優れています。 ただし、 map + sync.Mutexまたはsync.RWMutexを使用して独自の型を作成することは、 sync.Mapが必要とする型アサーションがない場合と同じ複雑さです。

私の同期マップの使用は、タイプを作成する代わりに、横にvar myMapLock = sync.RWMutex{}があるミューテックスのグローバルマップに使用されています。 これはもっときれいかもしれません。 一般的な組み込み型は私には正しいように聞こえますが、私にはできない作業が必要であり、型をアサートするよりも私のアプローチを好みます。

ジェネリックスへの主な露出がC ++テンプレートを介していたため、多くのGoプログラマーが持っていると思われるジェネリックスに対する否定的な内臓反応が生じているのではないかと思います。 これは残念なことです。なぜなら、C ++は初日からジェネリックスを悲劇的に間違ってしまい、それ以来その間違いを悪化させてきたからです。 Goのジェネリックは、はるかに単純でエラーが発生しにくい可能性があります。

組み込みのパラメーター化された型を追加することによってGoがますます複雑になるのを見るのは残念です。 プログラマーが独自のパラメーター化された型を作成するための言語サポートを追加する方がよいでしょう。 そうすれば、特別なタイプは、コア言語を乱雑にするのではなく、ライブラリとして提供することができます。

@andrewcmyers "Generics for Goは、はるかに単純でエラーが発生しにくい可能性があります。" --- C＃のジェネリックのように。

組み込みのパラメーター化された型を追加することによってGoがますます複雑になるのを見るのは残念です。

この問題の憶測にもかかわらず、私はこれが起こる可能性は非常に低いと思います。

パラメータ化されたタイプの複雑さの尺度の指数は分散です。
Goのタイプ（インターフェースを除く）は不変であり、これは可能であり、そうあるべきです
ルールを守った。

機械的なコンパイラ支援の「typecopy-paster」ジェネリックスの実装
Goの根底にある方法で問題の99％を解決します
浅さと非驚きの原則。

ちなみに、これと他の数十の実行可能なアイデアが議論されています
以前、そしていくつかは、良い、実行可能なアプローチで最高潮に達しました。 これで
ポイント、私は境界線のtinfoilです-それらがすべてどのように消えたかについて悩んでいます
静かに空虚に。

2017年11月28日23:54、「AndrewMyers」 [email protected]は次のように書いています。

多くの人が行っているジェネリック医薬品に対する否定的な内臓反応が疑われます
プログラマーは、ジェネリック医薬品への主な露出が
C ++テンプレートを介して。 C ++がジェネリックを悲劇的に入手したため、これは残念なことです
初日から間違っていて、それ以来間違いを悪化させています。 ジェネリック医薬品
Goは、はるかに単純でエラーが発生しにくい可能性があります。

Goが追加することでますます複雑になるのを見るのは残念です
組み込みのパラメーター化された型。 言語を追加するだけの方がいいでしょう
プログラマーが独自のパラメーター化された型を作成するためのサポート。 そうして
特別なタイプは、雑然とせずにライブラリとして提供することができます
コア言語。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment-347691444 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AJZ_jPsQd2qBbn9NI1wZeT-O2JpyraTMks5s7I81gaJpZM4IG-xv
。

はい、テンプレートなしでジェネリックを使用できます。 テンプレートは、主にメタプログラミング機能のための高度なパラメトリックポリモーフィズムの形式です。

@ianlancetaylor Rustを使用すると、クレートがTまたはQのいずれかを定義している場合、プログラムは既存のタイプQにトレイトTを実装できます。

ちょっと考えてみてください。サイモンペイトンジョーンズ（そう、Haskellの名声）やRust開発者が助けてくれるのではないかと思います。 RustとHaskellは、おそらくあらゆる生産言語の中で最も先進的な2つの型システムを持っており、Goはそれらから学ぶ必要があります。

GenericJavaに取り組んだPhillipWadlerもいます。これは、最終的にJavaが今日持っているジェネリックの実装につながります。

@tarcieri Javaのジェネリックはあまり良いとは思いませんが、それらはバトルテスト済みです。

@DemiMarie幸い、AndrewMyersがここにピッチングしました。

私の個人的な経験からすると、さまざまな言語やさまざまな型システムについてよく知っている人は、アイデアを検討するのに非常に役立つと思います。 しかし、そもそもアイデアを生み出すために必要なのは、Goに精通している人々、現在のGoの仕組み、そして将来の合理的な仕組みです。 Goは、とりわけ単純な言語になるように設計されています。 Goよりもはるかに複雑なHaskellやRustなどの言語からアイデアをインポートすることは、適切ではない可能性があります。 そして、一般的に、適度な量のGoコードをまだ作成していない人々からのアイデアは、適切ではない可能性があります。 アイデア自体が悪いというわけではなく、他の言語とうまく適合しないというだけです。

たとえば、Goは、インターフェイスタイプを使用したジェネリックプログラミングをすでに部分的にサポートしており、reflectパッケージを使用して（ほぼ）完全にサポートしていることを理解することが重要です。 ジェネリックプログラミングへのこれら2つのアプローチはさまざまな理由で不十分ですが、Goでのジェネリックの提案は、それらとうまく相互作用すると同時に、それらの欠点に対処する必要があります。

実際、私がここにいる間、しばらく前にインターフェースを使ったジェネリックプログラミングについて考え、それが満足のいくものではない3つの理由を思いつきました。

1. インターフェイスでは、すべての操作をメソッドとして表現する必要があります。 そのため、チャネルタイプなどの組み込みタイプのインターフェイスを作成するのは面倒です。 すべてのチャネルタイプは、送受信操作の<-演算子をサポートしており、 Send ＃$メソッドとReceiveメソッドを使用してインターフェイスを作成するのは簡単ですが、チャネル値を割り当てるためにそのインターフェイスタイプには、ボイラープレートプレートSendおよびReceiveメソッドを作成する必要があります。 これらの定型的な方法は、チャネルタイプごとにまったく同じように見えますが、これは面倒です。

2. インターフェイスは動的に型付けされるため、静的に型付けされたさまざまな値を組み合わせたエラーは、コンパイル時ではなく、実行時にのみキャッチされます。 たとえば、 Send $メソッドとReceiveメソッドを使用して2つのチャネルを1つのチャネルにマージするMerge関数では、2つのチャネルに同じタイプの要素が必要ですが、チェックは実行時にのみ実行できます。

3. インターフェイスは常にボックス化されています。 たとえば、インターフェイスを使用して他のタイプのペアを集約するには、他のタイプをインターフェイス値に入れる必要があり、追加のメモリ割り当てとポインタ追跡が必要になります。

Goのジェネリック医薬品の提案についてキビッツに喜んでいます。 おそらくまた興味深いのは、最近コーネル大学でジェネリック医薬品に関する研究が増えていることであり、Goで行われる可能性のあることに関連しているようです。

http://www.cs.cornell.edu/andru/papers/familia/（Zhang＆Myers、OOPSLA'17 ）
http://io.livecode.ch/learn/namin/unsound（Amin＆Tate、OOPSLA'16 ）
http://www.cs.cornell.edu/projects/genus/（Zhang et al。、PLDI '15）
https://www.cs.cornell.edu/~ross/publications/shapes/shapes-pldi14.pdf（Greenman、Muehlboeck＆Tate、PLDI '14）

順序付けされていないセットタイプのベンチマークマップとスライスでは、それぞれに個別の単体テストを作成しましたが、インターフェイスタイプを使用すると、これら2つのテストリストを1つにまとめることができます。

type Item interface {
    Equal(Item) bool
}

type Set interface {
    Add(Item) Set
    Remove(Item) Set
    Combine(...Set) Set
    Reduce() Set
    Has(Item) bool
    Equal(Set) bool
    Diff(Set) Set
}

アイテムの削除のテスト：

type RemoveCase struct {
    Set
    Item
    Out Set
}

func TestRemove(t *testing.T) {
    for i, c := range RemoveCases {
        if c.Out.Equal(c.Set.Remove(c.Item)) == false {
            t.Fatalf("%v failed", i)
        }
    }
}

このようにして、以前は別々だったケースを問題なく1つのケースにまとめることができます。

var RemoveCases = []RemoveCase{
    {
        Set: MapPathSet{
            &Path{{0, 0}}:         {},
            &Path{{0, 1}, {1, 1}}: {},
        },
        Item: Path{{0, 0}},
        Out: MapPathSet{
            &Path{{0, 1}, {1, 1}}: {},
        },
    },
    {
        Set: SlicePathSet{
            {{0, 0}},
            {{0, 1}, {1, 1}},
        },
        Item: Path{{0, 0}},
        Out: SlicePathSet{
            {{0, 1}, {1, 1}},
        },
    },
}

具体的なタイプごとに、インターフェイスメソッドを定義する必要がありました。 例えば：

func (the MapPathSet) Remove(an Item) Set {
    return MapDelete(the, an.(Path))
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an.(Path))
}

これらの一般的なテストでは、提案されたコンパイル時の型チェックを使用できます。

type Item generic {
    Equal(Item) bool
}

func (the SlicePathSet) Remove(an Item) Set {
    return SliceDelete(the, an)
}

ソース： https ：//github.com/pciet/pathsetbenchmark

さらに考えてみると、型が対応するインターフェイスメソッドに渡されるかどうかを知るためにプログラムを実行する必要があるため、このようなテストではコンパイル時の型チェックは不可能であるように思われます。

では、具体的に使用すると、インターフェイスであり、コンパイラによって非表示の型アサーションが追加された「ジェネリック」型についてはどうでしょうか。

@andrewcmyers 「ファミリア」の論文は面白かった（そして私の頭をはるかに超えていた）。 重要な概念は遺伝でした。 継承ではなく構成に依存するGoのような言語の概念はどのように変わりますか？

ありがとう。 継承の部分はGoには適用されません。Goのジェネリックにのみ関心がある場合は、ペーパーのセクション4の後で読むのをやめることができます。 Goに関連するこのペーパーの主な点は、現在Goで使用されている方法と、一般的な抽象化の型の制約としての両方でインターフェイスを使用する方法を示していることです。 つまり、言語にまったく新しい構造を追加することなく、Haskell型クラスのパワーを手に入れることができます。

@andrewcmyersこれがGoでどのように見えるかの例を挙げていただけますか？

Goに関連するその論文の主な点は、現在Goで使用されている方法と、一般的な抽象化の型の制約としての両方でインターフェースを使用する方法を示していることです。

私の理解では、Goインターフェースは型に対する制約を定義します（たとえば、「この型は、Eqメソッドを持つことを満足するため、「typeComparableinterface」を使用して同等性を比較できます」）。 型制約の意味がよくわかりません。

私はHaskellに精通していませんが、簡単な概要を読むと、Goインターフェイスに適合する型がその型クラスに適合すると推測できます。 Haskell型クラスの違いを説明できますか？

FamiliaとGoの具体的な比較は興味深いでしょう。 論文を共有していただきありがとうございます。

Goインターフェースは、構造サブタイピングを介して、型の制約を記述していると見なすことができます。 ただし、その型制約は、そのままでは、ジェネリックプログラミングに必要な制約をキャプチャするのに十分な表現力がありません。 たとえば、Familiaの論文ではEqという名前の型制約を表現することはできません。

Goのより一般的なプログラミング機能の動機に関するいくつかの考え：

したがって、言語に何も追加する必要のない一般的なテストリストがあります。 私が提案したジェネリック型は、単純な理解というGoの目標を満たしていない、一般的に受け入れられているプログラミング用語とはあまり関係がない、そして失敗のパニックが大丈夫。 私は、Goのジェネリックプログラミング機能にすでに満足しています。

ただし、sync.Mapは別のユースケースです。 標準ライブラリには、マップとミューテックスを備えた構造体だけでなく、成熟した汎用同期マップの実装が必要です。 型処理の場合、非インターフェイス{}型を設定し、型アサーションを実行する別の型でラップするか、内部でリフレクトチェックを追加して、最初の項目に続く項目が同じ型と一致する必要があります。 どちらにもランタイムチェックがあり、ラッピングでは使用タイプごとに各メソッドを書き直す必要がありますが、入力のコンパイル時タイプチェックが追加され、出力タイプアサーションが非表示になります。内部チェックでは、とにかく出力タイプアサーションを実行する必要があります。 いずれにせよ、実際にインターフェースを使用せずにインターフェース変換を行っています。 interface {}は言語のハックであり、新しいGoプログラマーにはわかりません。 json.Marshalは私の意見では良いデザインですが（醜いが賢明な構造体タグを含む）。

sync.Mapは標準ライブラリにあるので、理想的には、単純な構造体のパフォーマンスが高い測定されたユースケースの実装を交換する必要があることを追加します。 同期されていないマップは、Go並行プログラミングの一般的な初期の落とし穴であり、標準ライブラリの修正が機能するはずです。

通常のマップにはコンパイル時の型チェックのみがあり、このスキャフォールディングは必要ありません。 sync.Mapは同じであるか、Go2の標準ライブラリに含まれていてはならないことを主張します。

組み込み型のリストにsync.Mapを追加し、将来の同様のニーズに対して同じことを行うことを提案しました。 しかし、私の理解では、Goプログラマーに、コンパイラーで作業することなくこれを行う方法を提供し、オープンソースの受け入れガントレットを通過することがこの議論の背後にある考え方です。 私の見解では、sync.Mapを修正することは、このジェネリックスの提案がどうあるべきかを部分的に定義する実際のケースです。

sync.Mapを組み込みとして追加する場合、どこまで進みますか？ すべてのコンテナに特別なケースがありますか？
sync.Mapだけがコンテナではなく、場合によっては他のコンテナよりも優れているものもあります。

@Azareal ： @choweyは8月にこれらをリストしました：

最後に、標準ライブラリには、ジェネリックスがより安全に機能するインターフェイス{}の選択肢がたくさんあります。

•heap.Interface（https://golang.org/pkg/container/heap/#Interface）
•list.Element（https://golang.org/pkg/container/list/#Element）
•ring.Ring（https://golang.org/pkg/container/ring/#Ring）
•sync.Pool（https://golang.org/pkg/sync/#Pool）
•今後のsync.Map（https://tip.golang.org/pkg/sync/#Map）
•atomic.Value（https://golang.org/pkg/sync/atomic/#Value）

私が行方不明になっている他の人がいるかもしれません。 重要なのは、上記のそれぞれがジェネリックスが役立つと私が期待するところです。

そして、同等性を比較できるタイプの順序付けられていないセットが欲しいです。

ベンチマークに基づいて、実行時に各タイプの変数実装に多くの作業を加えて、可能な限り最良の実装が通常使用されるものになるようにしたいと思います。

インターフェイス{}やジェネリックスなしでこれらの標準ライブラリタイプに対して同じ目標を達成する、Go1を使用した合理的な代替実装があるかどうか疑問に思います。

golangインターフェースとhaskell型クラスは2つのことを克服します（これは非常に素晴らしいです！）：

1。）（タイプ制約）異なるタイプを1つのタグ（インターフェース名）でグループ化します
2。）（ディスパッチ）インターフェイスの実装を介して、特定の機能セットのタイプごとに異なるディスパッチを提供します

しかし、

1.）int、float64、stringのグループのような匿名グループのみが必要な場合があります。 そのようなインターフェースにNumericandStringという名前を付ける必要がありますか？

2.）多くの場合、インターフェイスのタイプごとに異なる方法でディスパッチするのではなく、リストされているすべてのタイプのインターフェイスに対して1つのメソッドのみを提供します（インターフェイスのデフォルトのメソッドで可能かもしれません）。

3.）多くの場合、グループで考えられるすべてのタイプを列挙する必要はありません。 代わりに、怠惰な方法で、すべてのタイプTにインターフェイスAとコンパイラを実装して、編集するすべてのソースファイルと、コンパイル時に適切な関数を生成するために使用するすべてのライブラリですべてのタイプを検索すると言います。

最後のポイントはインターフェイスポリモーフィズムを介して行うことは可能ですが、キャストを含むランタイムポリモーフィズムであるという欠点があり、関数のパラメータ入力を制限して、複数のインターフェイスまたは多くのインターフェイスの1つを実装する型を含めるにはどうすればよいですか。 成功する方法は、他のインターフェイスを拡張する新しいインターフェイスを導入して（インターフェイスのネストによって）、同様のことを実現することですが、ベストプラクティスではありません。

ところで。
goはすでにポリモーフィズムを持っているので、goはもはやCのような単純な言語ではないと言う人たちに認めます。これは高レベルのシステムプログラミング言語です。 では、ポリモーフィズムを拡張してみませんか。

これが私が今日始めた一般的な順序付けされていないセットタイプのライブラリです： https ：//github.com/pciet/unordered

これにより、コンパイル時の型の安全性のための型ラッパーパターン（@pierrreに感謝）のドキュメントとテスト例が提供され、実行時の型の安全性の反映チェックも行われます。

ジェネリック医薬品にはどのようなニーズがありますか？ 以前の標準ライブラリのジェネリック型に対する私の否定的な態度は、インターフェイスの使用に集中していました{}; 私の苦情は、意図された表現できない制約を文書化するinterface {}のパッケージ固有のタイプ（pciet / unorderedのtype Item interface{}など）で解決できます。

ドキュメントだけで言語機能を追加できるようになったのに、言語機能を追加する必要はないと思います。 汎用機能を提供する標準ライブラリには、すでに大量のバトルテスト済みコードがあります（https://github.com/golang/go/issues/23077を参照）。

あなたのコードは実行時にタイプチェックします（そしてその観点からは、悪くないにしてもinterface{}よりも決して良いことはありません）。 ジェネリックスを使用すると、コンパイル時の型チェックを使用してコレクション型を作成できます。

@zerkmsの実行時チェックは、asserting = false（これは標準ライブラリには含まれません）を設定することでオフにできます。コンパイル時チェックには使用パターンがあり、とにかく型チェックはインターフェイス構造体を確認するだけです（インターフェイスは、タイプチェックよりも多くの費用を追加します）。 インターフェイスが機能していない場合は、独自のタイプを作成する必要があります。

パフォーマンスを最大化するジェネリックコードが重要なニーズであるとおっしゃっています。 私のユースケースではそうではありませんでしたが、標準ライブラリがより高速になる可能性があり、他の人がそのようなことを必要としている可能性があります。

実行時チェックは、asserting = falseを設定することでオフにできます

その後、正確さを保証するものは何もありません

パフォーマンスを最大化するジェネリックコードが重要なニーズであるとおっしゃっています。

私はそう言いませんでした。 型安全性は非常に重要です。 あなたのソリューションはまだinterface{}感染しています。

しかし、おそらく標準ライブラリはより速くなる可能性があり、他の人はそのようなものを必要とするかもしれません。

コア開発チームが必要なものをオンデマンドで迅速に実装できれば、そうかもしれません。

@pciet

ドキュメントだけで言語機能を追加できるようになったのに、言語機能を追加する必要はないと思います。

あなたはこれを言います、それでもあなたはスライスとmake関数の形で一般的な言語機能を使うことに問題はありません。

ドキュメントだけで言語機能を追加できるようになったのに、言語機能を追加する必要はないと思います。

では、なぜ静的に型付けされた言語をわざわざ使用するのでしょうか。 Pythonのような動的型付け言語を使用し、ドキュメントに依存して、正しいデータ型がAPIに送信されることを確認できます。

Goの利点の1つは、将来のバグを防ぐためにコンパイラーによっていくつかの制約を適用できることだと思います。 これらの機能を拡張して（ジェネリックスのサポートを使用して）、他のいくつかの制約を適用して、将来のバグを防ぐことができます。

あなたはこれを言います、それでもあなたはスライスとmake関数の形で一般的な言語機能を使うことに問題はありません。

私は、既存の機能によって、ジェネリックプログラミングソリューションを備えたバランスの取れたポイントに到達し、Go1タイプのシステムから変更する強い本当の理由があるはずだと言っています。 変更によって言語がどのように改善されるかではなく、fmtおよびデータベースの標準ライブラリパッケージでinterface {}の実行時型の切り替えを多く維持するなど、人々が現在直面している問題は修正されます。

では、なぜ静的に型付けされた言語をわざわざ使用するのでしょうか。 Pythonのような動的型付け言語を使用し、ドキュメントに依存して、正しいデータ型がAPIに送信されることを確認できます。

静的に型付けされた言語や組織ではなく、Pythonでシステムを作成するという提案を聞いたことがあります。

標準ライブラリを使用するほとんどのGoプログラマーは、ドキュメントなしで、または実装を見ずに完全に説明できないタイプを使用します。 パラメトリックサブタイプのあるタイプまたは制約が適用された一般的なタイプは、これらのケースのサブセットをプログラムで修正するだけであり、標準ライブラリですでに行われている多くの作業を生成します。

合計型の提案では、関数またはメソッドでのインターフェイスの使用で、インターフェイスに割り当てられた可能な値が含まれているインターフェイスタイプスイッチのケースと一致しない場合にビルドエラーが発生する、インターフェイスタイプスイッチのビルド機能を提案しました。

インターフェイスを使用する関数/メソッドは、デフォルトの大文字と小文字がなく、型の大文字と小文字がないため、ビルド時に一部の型を拒否する可能性があります。 機能を実装できる場合、これは妥当なジェネリックプログラミングの追加のように思われます。

Goインターフェースが実装者のタイプをキャプチャできる場合、現在のGo構文と完全に互換性のあるジェネリックの形式（ジェネリックの単一パラメーター形式（デモンストレーション））が存在する可能性があります。

ジェネリックコンテナータイプの場合は@ dc0dこの機能により、ラッパータイプを必要とせずにコンパイル時のタイプチェックが追加されると思います： https ：//gist.github.com/pciet/36a9dcbe99f6fb71f5fc2d3c455971e5

@pcietその通りです。 提供されたコードNo.4では、サンプルは、タイプがスライスとチャネル（および配列）に対してキャプチャされていることを示しています。 ただし、マップの場合はそうではありません。タイプパラメータは実装者だけだからです。 また、マップには2つのタイプのパラメーターが必要なため、ラッパーインターフェイスが必要です。

ところで、私は考えの線として、そのコードのデモンストレーションの目的を強調する必要があります。 私は言語デザイナーではありません。 これは、Goでのジェネリックスの実装についての単なる架空の考え方です。

• 現在のGoと互換性があります
• 単純（現在の実装者を参照して、他のOOの_this_のように_感じる_単一のジェネリック型パラメーター）

重要なユースケースと表現の柔軟性を最大化しながら、影響を最小限に抑えたいという願望の文脈での一般性とすべての可能なユースケースの議論は、非常に複雑な分析です。 私たちの誰かがそれを短い原則のセット、別名生成的本質に蒸留することができるかどうかはわかりません。 私はしようとしています。 とにかく、ここでこのスレッドの私の_cursory_熟読からの私の最初の考えのいくつか…

@adgは書いた：

この問題に付随するのは、 @ ianlancetaylorによるジェネリックジェネリックの提案であり、Goのジェネリックプログラミングメカニズムの4つの特定の欠陥のある提案が含まれています。

Afaics、以下のように抜粋されたリンクされたセクションは、現在のインターフェースに欠けている一般性のケースを述べることができません。同じタイプT。」_。

任意のTに対して、タイプTの引数を取り、同じタイプの値を返すメソッドを使用してインターフェースを作成する方法はありません。

では、呼び出しサイトのタイプのコードが、結果値としてタイプTを持っていることを他にどのようにチェックできるでしょうか。 たとえば、前述のインターフェイスには、タイプTを構築するためのファクトリメソッドがある場合があります。これが、タイプTのインターフェイスをパラメータ化する必要がある理由です。

インターフェイスは単なるタイプではありません。 それらは値でもあります。 インターフェイス値を使用せずにインターフェイスタイプを使用する方法はありません。また、インターフェイス値が常に効率的であるとは限りません。

インターフェースは現在、操作するタイプTで明示的にパラメーター化できないため、プログラマーはタイプTにアクセスできないことに同意しました。

したがって、これは、型Tを入力として受け取り、型Tに必要なインターフェイスを示すwhereまたはrequires句を持つ、関数定義サイトでの型クラス境界の動作です。多くの状況でこれらのインターフェイスディクショナリは、コンパイル時に自動的に単形化できるため、実行時に（インターフェイス用の）ディクショナリポインタが関数に渡されません（Goコンパイラが現在インターフェイスに適用されていると思いますか？）。 上記の引用の「値」によって、彼は入力タイプTを意味し、タイプTによって実装されたインターフェースタイプのメソッドの辞書ではないと推測します。

次に、データ型の型パラメーターを許可すると（たとえば、 struct ）、上記の型T自体をパラメーター化できるため、実際には型T<U>なります。 Uの知識を保持する必要があるこのようなタイプのファクトリは、高種類タイプ（HKT）と呼ばれます。

ジェネリックスは、タイプセーフなポリモーフィックコンテナを許可します。

また、以下で説明する_heterogeneous_コンテナの問題も参照してください。 したがって、多態性とは、コンテナの値型（コレクションの要素型など）の一般性を意味しますが、コンテナに複数の値型を同時に配置してそれらを異種化できるかどうかという問題もあります。

@tamirdは書いた：

これらの要件は、たとえば、ジェネリック型が特性の境界によって制約されるRustの特性システムと同様のシステムを除外しているようです。

Rustの特性境界は、本質的に型クラスの境界です。

@alexは書いた：

さびの特徴。 一般的には良いモデルだと思いますが、現在のGoには不向きです。

なぜ彼らは不適合だと思いますか？ おそらく、ランタイムディスパッチを使用する特性オブジェクトは、単相性よりもパフォーマンスが低いと考えていますか？ しかし、それらは型クラス境界の一般性の原則とは別に考えることができます（以下の異種コンテナー/コレクションの私の議論を参照してください）。 Afaics、Goのインターフェースはすでに特性のような境界であり、（コンパイル時であっても）早期にバインドするOOPのアンチパターンではなく、呼び出しサイトでデータ型に辞書を遅延バインドするという型クラスの目標を達成します。時間）データ型への辞書（インスタンス化/構築時）。 型クラスは（少なくとも部分的に自由度を改善して）OOPでは解決できない式の問題を解決できます。

@jimmyfrascheは書いた：

• https://golang.org/doc/faq#covariant_types

私は、型クラスが実際にサブタイピングされておらず、継承関係を表現していないという上記のリンクに同意します。 そして、サブクラス化のように、「一般性」（パラメトリック多型よりも再利用またはモジュール性のより一般的な概念として）を継承と不必要に混同しないことに同意します。

ただし、言語が和集合と共通部分をサポートしている場合、継承階層（サブタイピング）は（関数入力）への割り当てと（関数出力）からの割り当てで不可避¹であることも指摘したいと思います。たとえば、 int ν string intまたはstringからの割り当てを受け入れることはできますが、どちらもint ν stringからの割り当てを受け入れることはできません。 ユニオンがない場合、静的に型付けされた異種コンテナー/コレクションを提供する唯一の代替方法は、サブクラス化または存在境界のポリモーフィズム（RustのトレイトオブジェクトおよびHaskellの存在記号）です。 上記のリンクには、実存主義と組合の間のトレードオフに関する議論が含まれています。 ^Afaik 、Goで異種のコンテナー/コレクションを実行する唯一の方法は、すべてのタイプを空のinterface{}に含めることです。これにより、タイピング情報が破棄され、キャストとランタイムタイプの検査が必要になると思います。静的型付けのポイントを打ち負かします。

避けるべき「アンチパターン」は、別名仮想継承をサブクラス化することです（暗黙の包含と平等の問題などについては、 「EDIT＃2」も参照してください）。

¹_{サブタイピングは、比較セットに基づくリスコフの置換原則と、戻り値とは反対の関数入力（たとえば、 structまたはinterfaceの型パラメーター）による割り当ての方向によるため、構造的に一致するか名目上一致するかに関係なく}

²_{無制限の非決定性の世界をタイプチェックできないため、絶対主義は適用されません。 ですから、私が理解しているように、このスレッドは、一般性の問題に対してタイピングを述べるレベルに最適な（「スイートスポット」）制限を選択することについてです。}

@andrewcmyersは書いた：

JavaやC＃ジェネリックとは異なり、Genusジェネリックメカニズムはサブタイピングに基づいていません。

Java、Scala、Ceylon、およびC ++（ C ++テンプレートの問題とは関係ありません）からコピーしたくない最悪のアンチパターンは、継承とサブクラス化（構造的サブタイピングではありません）です。

@thwdは書いた：

パラメータ化されたタイプの複雑さの尺度の指数は分散です。 Goのタイプ（インターフェースを除く）は不変であり、これはルールを維持することができ、維持する必要があります。

不変性を使用したサブタイピングは、共分散の複雑さを回避します。 不変性は、サブクラス化に関する問題の一部（たとえば、 RectangleとSquare ）も改善しますが、他の問題（たとえば、暗黙の包含、平等など）は改善しません。

@bxqgitは書いた：

単純な構文と型システムは、Goの重要な長所です。 ジェネリックスを追加すると、言語はScalaやHaskellのような醜い混乱になります。

Scalaは、OOP、サブクラス化、FP、汎用モジュール、HKT、および型クラス（ implicitを介して）をすべて1つのPLにマージしようとすることに注意してください。 おそらく型クラスだけで十分かもしれません。

Haskellは、型クラスのジェネリックスのために必ずしも鈍感ではありませんが、あらゆる場所で純粋関数を適用し、制御された命令型効果をモデル化するためにモナディック圏論を採用しているためです。

したがって、これらのPLの鈍感さと複雑さをRustなどの型クラスに関連付けるのは正しくないと思います。 そして、Rustの生涯+排他的な可変性借用の抽象化のタイプクラスを非難しないようにしましょう。

Afaics、Goの_Typeパラメータのセマンティクスセクションで、@ ianlancetaylorが遭遇する問題は、彼が（ afaics ）明らかに無意識のうちに型クラスを再発明しているため、概念化の問題です。

SortableSliceとPSortableSliceをマージして、両方の長所を活かすことができますか？ 完全ではありません。 Lessメソッドを持つ型または組み込み型のいずれかをサポートするパラメーター化された関数を作成する方法はありません。 問題は、 SortableSlice.Lessは、 Lessメソッドがないとタイプに対してインスタンス化できないことです。また、一部のタイプに対してのみメソッドをインスタンス化する方法はなく、他のタイプに対してはインスタンス化する方法がありません。

$ []TのLessメソッドの型クラスバインドのrequires Less[T]句は、 []T Tにあります。 []T 。 TごとにLess[T]型クラス（メソッドLessメソッドを含む）を実装すると、メソッドの関数本体に実装が提供されるか、 <が割り当てられます。実装としてのSortable[U]のメソッドが実装型を表す型パラメーターUを必要とする場合、これにはHKT U[T]が必要だと思います（例： []T 。 Afair @keeanには、HKTを必要としない値型Tの個別の型クラスを使用してソートを構造化する別の方法があります。

[]Tのこれらのメソッドは、 Sortable[U]型クラスを実装している可能性があることに注意してください。ここで、 Uは[]Tです。

（技術的な側面： SortableSliceとPSortableSliceは、一部の型引数のメソッドをインスタンス化するだけで、他の型引数のメソッドをインスタンス化しないメカニズムを使用することでマージできるように見えるかもしれません。ただし、結果としてコンパイルが犠牲になります。 -時間型の安全性。間違った型を使用すると実行時のパニックが発生します。Goでは、インターフェイスの型とメソッド、および型アサーションを使用して実行時の動作を選択できます。型パラメーターを使用してこれを行う別の方法を提供する必要はありません。 。）

呼び出しサイトでバインドされた型クラスの選択は、静的に既知のTのコンパイル時に解決されます。 異種の動的ディスパッチが必要な場合は、以前の投稿で説明したオプションを参照してください。

@keeanがここに来て、型クラスを説明するのに役立つことを願っています。彼はより専門的であり、これらの概念を学ぶのを助けてくれました。 説明に誤りがあるかもしれません。

私の以前の投稿をすでに読んだ人のためのPSノート、私はそれを投稿してから約10時間後（ある程度の睡眠の後）にそれを広範囲に編集したことに注意してください。

サイクルセクションが正しくないようです。 structのS[T]{e}インスタンスの実行時の構築は、呼び出されるジェネリック関数の実装の選択とは何の関係もありません。 彼はおそらく、コンパイラーが引数の型のジェネリック関数の実装を特殊化しているかどうかを知らないと考えていますが、それらの型はすべてコンパイル時に認識されています。

おそらく、タイプチェックセクションの仕様は、統合アルゴリズムのノードとしての異なるタイプの連結グラフの@keeanの概念を研究することによって簡略化できます。 エッジによって接続された個別のタイプは、合同タイプである必要があります。エッジは、割り当てまたはソースコード内で接続するタイプ用に作成されます。 （私の以前の投稿からの）結合と共通部分がある場合は、割り当ての方向を考慮に入れる必要があります（どういうわけか？ ）。 それぞれの異なる未知のタイプは、上界の最小上限（LUB）と下界の最大下限（ GLB ）で始まり、制約によってこれらの境界が変更される可能性があります。 接続されたタイプには、互換性のある境界が必要です。 制約はすべて型クラスの境界である必要があります。

実装中：

たとえば、インスタンス化ごとに関数の新しいコピーを生成することでパラメーター化された関数を実装できます。新しい関数は、型パラメーターを型引数に置き換えることで作成されます。

正しい専門用語は単形化だと思います。

このアプローチでは、かなりの余分なコンパイル時間とコードサイズの増加を犠牲にして、最も効率的な実行時間が得られます。 インライン化するのに十分小さいパラメーター化された関数には適している可能性がありますが、他のほとんどの場合はトレードオフとしては不十分です。

プロファイリングは、どの関数が単形化から最も恩恵を受けることができるかをプログラマーに伝えます。 おそらく、Java Hotspotオプティマイザーは実行時に単形化の最適化を行いますか？

@egonelbreは書いた：

さまざまな場所からのディスカッションの概要を提供しようとするGoGenericsディスカッションの概要があります。

概要セクションは、コンテナ内のインスタンスに対するJavaのボクシング参照の普遍的な使用が、C ++によるテンプレートの単形化に正反対の設計の唯一の軸であることを示唆しているようです。 ただし、型クラスの境界（ C ++テンプレートでも実装できますが、常に単相化されます）は、コンテナー型パラメーターではなく関数に適用されます。 したがって、概要には、各型クラス有界関数を単形化するかどうかを選択できる型クラスの設計軸がありません。 型クラスを使用すると、プログラマーは常に高速になり（定型文が少なくなり）、コンパイラー/実行を高速/低速にすることとコードの膨張を大きく/小さくすることの間でより洗練されたバランスをとることができます。 私の以前の投稿によると、おそらく最適なのは、単形化する関数の選択がプロファイラー駆動型である場合です（自動的に、またはアノテーションによって可能性が高くなります）。

問題：一般的なデータ構造セクション：

短所

• 一般的な構造は、あらゆる用途の機能を蓄積する傾向があるため、コンパイル時間の増加やコードの膨張、またはよりスマートなリンカーの必要性が生じます。

型クラスの場合、これは当てはまらないか、それほど問題にはなりません。インターフェイスは、それらのインターフェイスを使用する関数に提供されるデータ型に対してのみ実装する必要があるためです。 タイプクラスは、すべてのデータ型をclass実装のメソッドにバインドするOOPとは異なり、実装のインターフェイスへの遅延バインディングに関するものです。

同様に、すべてのメソッドを単一のインターフェースに配置する必要はありません。 関数宣言にバインドされた型クラスのrequires句（コンパイラによって暗黙的に推測された場合でも）は、必要なインターフェイスを組み合わせることができます。

• 一般的な構造とそれらを操作するAPIは、専用のAPIよりも抽象的である傾向があり、発信者に認知的負担を課す可能性があります

この懸念を大幅に改善すると私が思う反論は、本質的に同じ遺伝的アルゴリズムの無制限の数の特殊なケースの再実装を学習することの認知的負担は無制限であるということです。 一方、抽象的な汎用APIの学習には限界があります。

• 詳細な最適化は非常に非一般的でコンテキスト固有であるため、一般的なアルゴリズムで最適化することは困難です。

これは有効な詐欺ではありません。 80/20の法則は、プロファイリング時にそれを必要としないコードに無制限の複雑さ（たとえば、時期尚早の最適化）を追加しないことを示しています。 プログラマーは、ケースの20％で自由に最適化できますが、残りの80％は、汎用APIの制限された複雑さと認知的負荷によって処理されます。

ここで実際に得ているのは、言語の規則性と汎用APIの助けであり、それを損なうものではありません。 これらの短所は実際には正しく概念化されていません。

代替ソリューション：

• 複雑な構造ではなく、より単純な構造を使用する
  
  
  
  • たとえば、Setの代わりにmap [int] struct {}を使用します
  
  

Rob Pike（そして私も彼がビデオでその点を指摘しているのを見ました）は、ジェネリックコンテナーがジェネリック関数を作成するのに十分ではないという点を見逃しているようです。 map[T]にTが必要です。これにより、入力、出力、および独自のstructの関数でジェネリックデータ型を渡すことができます。 コンテナタイプパラメータのジェネリックのみは、ジェネリックAPIを表現するには完全に不十分であり、ジェネリックAPIは、制限された複雑さと認知的負荷、および言語エコシステムでの規則性の取得に必要です。 また、非ジェネリックコードが必要とするリファクタリングのレベルの増加（したがって、簡単にリファクタリングできないモジュールの構成可能性の低下）は見ていません。これは、最初の投稿で述べた式の問題です。

一般的なアプローチのセクション：

パッケージテンプレート
これは、Modula-3、OCaml、SML（いわゆる「ファンクター」）、およびAdaで使用されるアプローチです。 特殊化のために個々のタイプを指定する代わりに、パッケージ全体が汎用です。 インポート時に型パラメーターを修正することにより、パッケージを特殊化します。

私は間違っているかもしれませんが、これは完全には正しくないようです。 MLファンクター（FPファンクターと混同しないでください）は、タイプパラメーター化されたままの出力を返すこともできます。 そうでなければ、他のジェネリック関数内でアルゴリズムを使用する方法はありません。したがって、ジェネリックモジュールは、他のジェネリックモジュールに（具象型でインポートすることによって）再利用できません。 これは、単純化しすぎて、ジェネリックス、モジュールの再利用などのポイントを完全に見逃そうとする試みのようです。

むしろ私の理解では、そのパッケージ（別名モジュール）タイプのパラメーター化により、タイプパラメーターをstruct 、 interface 、およびfuncのグループに適用できるようになります。

より複雑な型システム
これは、HaskellとRustが採用しているアプローチです。
[…]
短所：

• 単純な言語に合わせるのは難しい（https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwGlB-n40kJ）

リンクされたドキュメントで@ianlancetaylorを引用します。

あなたがそれを信じるなら、それはそのコアが
Goランタイムのマップおよびスライスコードは、次の意味で一般的ではありません。
型ポリモーフィズムを使用します。 それはそれが見るという意味で一般的です
反射情報を入力して、移動方法とタイプの比較方法を確認します
値。 ですから、私たちは存在によって、書くことが許容できるという証拠を持っています
タイプを使用する非ポリモーフィックコードを記述することによるGoの「ジェネリック」コード
リフレクション情報を効率的に、そしてそのコードをラップする
コンパイル時のタイプセーフボイラープレート（マップとスライスの場合）
もちろん、このボイラープレートはコンパイラによって提供されます）。

これが、ジェネリックスが追加されたGoのスーパーセットからトランスパイルするコンパイラーがGoコードとして出力するものです。 しかし、ラッピングは、パッケージなどの描写に基づいていません。これは、すでに述べた構成可能性に欠けているためです。 優れたコンポーザブルジェネリック型システムへの近道はないということを指摘してください。 正しく行うか、何もしないかのどちらかです。これは、実際にはジェネリックではないコンポーザブルではないハックを追加すると、最終的にはパッチワークの半ばのジェネリックのクラスターファック慣性とコーナーケースの不規則性、およびGoエコシステムコードを作成する回避策が作成されるためです。理解できない。

大規模で複雑なGoプログラムを作成するほとんどの人が
ジェネリック医薬品の重要な必要性は見つかりませんでした。 これまでのところ、
苛立たしい疣贅-のための定型文の3行を書く必要性
ソートされる各タイプ-有用な書き込みの大きな障壁ではなく
コード。

ええ、これは、本格的な型クラスシステムに移行することが正当であるかどうかという私の考えの1つです。 すべてのライブラリがそれに基づいている場合、それは明らかに美しい調和である可能性がありますが、一般性のために既存のGoハックの慣性について検討している場合、多くのプロジェクトで得られる追加の相乗効果は低くなるでしょう。 ？

しかし、型クラス構文からのトランスパイラーが、Goがジェネリックスをモデル化できる既存の手動の方法をエミュレートした場合（編集： @andrewcmyersの状態がもっともらしいと読んだだけです）、これはそれほど面倒ではなく、有用な相乗効果を見つける可能性があります。 たとえば、タプルをエミュレートするstructにinterfaceを実装すると、2つのパラメーター型クラスをエミュレートできることに気付きました。 @ jbaは、コンテキストでインラインinterfaceを使用するアイデアについて言及しました。 。 どうやらstructは、 typeの名前が​​付けられていない限り、名目上入力されるのではなく、構造的に入力されているようです。 また、 interfaceのメソッドが別のinterfaceを入力できることを確認したので、以前の投稿で書いたソート例でHKTからトランスパイルできる可能性があります。 しかし、私がそれほど眠くないときは、これをもっと考える必要があります。

GoチームのほとんどはC ++が好きではないと言っても過言ではないと思います
1つのチューリング完全言語が階層化されたテンプレート
2つの言語が持つような別のチューリング完全言語
完全に異なる構文であり、両方の言語のプログラムは
非常に異なる方法で書かれています。 C ++テンプレートは注意として機能します
複雑な実装が全体に浸透しているため、物語
標準ライブラリ。C++エラーメッセージが
不思議と驚き。 これは、Goがたどる道ではありません。

誰もが反対するのではないかと思います！ 単形化の利点は、チューリング完全ジェネリックメタプログラミングエンジンの欠点と直交しています。

ところで、C ++テンプレートの設計エラーは、生成的（適用的ではなく）MLファンクターの欠陥と同じ生成的本質であるように私には思えます。 最小電力の原則が適用されます。

@ianlancetaylorは書いた：

組み込みのパラメーター化された型を追加することによってGoがますます複雑になるのを見るのは残念です。

この問題の憶測にもかかわらず、私はこれが起こる可能性は非常に低いと思います。

そうだといい。 Goは、一貫性のあるジェネリックシステムを追加するか、ジェネリックがないことを受け入れるべきだと固く信じています。

トランスパイラーへのフォークが発生する可能性が高いと思います。これは、それを実装するための資金があり、そうすることに興味があるためです。 それでも私はまだ状況を分析しています。

それはエコシステムを破壊するでしょうが、少なくともその時、Goはそのミニマリストの原則に純粋であり続けることができます。 したがって、エコシステムの破壊を回避し、私が望む他のいくつかの革新を可能にするために、私はおそらくそれをスーパーセットにせず、代わりにゼロと名付けます。

@pcietは書いた：

私の投票は、一般化されたアプリケーションジェネリックに反対し、複数の基本タイプで機能するappendやcopyなどのより組み込みのジェネリック関数に賛成です。 おそらくsortとsearchをコレクションタイプに追加できますか？

この慣性を拡大すると、包括的なジェネリックス機能がGoに組み込まれるのを防ぐことができます。 ジェネリック医薬品が欲しかった人は、より環境に優しい牧草地に向かう可能性があります。 @andrewcmyersはこれを繰り返しました：

組み込みのパラメーター化された型を追加することによってGoがますます複雑になるのを見るのは残念です。 プログラマーが独自のパラメーター化された型を作成するための言語サポートを追加する方がよいでしょう。

@ shellby3

Afaik、Goで異種コンテナ/コレクションを実行する唯一の方法は、すべての型を空のインターフェイス{}に含めることです。これにより、型情報が破棄され、キャストとランタイム型検査が必要になると思います。静的型付け。

Goでのinterface {}コレクションの静的型チェックについては、上記のコメントのラッパーパターンを参照してください。

優れたコンポーザブルジェネリック型システムへの近道はないということを指摘してください。 正しく実行するか、何も実行しないかのどちらかです。これは、実際にはジェネリックではない、構成不可能なハックを追加するためです…

これについてもっと説明してもらえますか？ 含まれているアイテムの必要な一般的な動作を定義するインターフェイスを持つコレクションタイプの場合は、関数を作成するのが妥当と思われます。

@pcietこのコードは、 @ shelby3が記述し、アンチパターンを考慮していたのとまったく同じことを文字通り実行しています。 以前からの引用：

これにより、コンパイル時の型の安全性のための型ラッパーパターン（@pierrreに感謝）のドキュメントとテスト例が提供され、実行時の型の安全性の反映チェックも行われます。

タイプ情報が不足しているコードを取得し、タイプごとに、reflectを使用してキャストとランタイムタイプ検査を追加しています。 これはまさに@ shelby3が不平を言っていたものです。 私はこのアプローチを「手作業によるモノモルフィゼーション」と呼ぶ傾向があり、まさにコンパイラーにパントするのが最善だと思う退屈な雑用のようなものです。

このアプローチには、いくつかの欠点があります。

• 手作業またはgo generateのようなツールで保守されるタイプごとのラッパーが必要です
• （ツールの代わりに手作業で行う場合）実行時までキャッチされないボイラープレートでミスを犯す機会
• 静的ディスパッチではなく動的ディスパッチが必要です。静的ディスパッチは低速であり、より多くのメモリを使用します。
• コンパイル時の型アサーションではなく、実行時のリフレクションを使用します。これも低速です。
• 構成不可能：完全に具象型に作用し、型に型クラスのような（またはインターフェイスのような）境界を使用する機会はありません。ただし、抽象化する必要のある空でないインターフェイスごとに別の間接層を処理する場合を除きます。

これについてもっと説明してもらえますか？ 含まれているアイテムの必要な一般的な動作を定義するインターフェイスを持つコレクションタイプの場合は、関数を作成するのが妥当と思われます。

これで、具象型の代わりに、またはそれに加えて境界を使用する場合は、すべてのインターフェイス型に対して同じ型チェック定型文を作成する必要があります。 それはあなたが書かなければならない静的型ラッパーの（おそらく組み合わせの）爆発をさらに悪化させます。

また、私が知る限り、インターフェースの組み合わせの限界など、今日のGoの型システムではまったく表現できないという考えもあります。 私たちが持っていると想像してください：

type Foo interface {
    ...
}

type Bar interface {
    ...
}

純粋に静的な型チェックを使用して、 FooとBarの両方を実装する型が必要であることをどのように表現しますか？ 私の知る限り、これはGoでは不可能です（失敗する可能性のあるランタイムチェックに頼る以外は、静的型の安全性を避けます）。

タイプクラスベースのジェネリックシステムでは、これを次のように表現できます。

func baz<T Foo + Bar>(t T) {
    ...
}

@tarcieri

純粋に静的な型チェックを使用して、FooとBarの両方を実装する型が必要であることをどのように表現しますか？

単にそうのように：

type T interface {
    Foo
    Bar
}

func baz(t T) { ... }

@sbinetきちんとした、TIL

個人的には、ランタイムリフレクションは誤った機能だと思いますが、それは私だけです...誰かが興味を持っているのなら、その理由を説明できます。

あらゆる種類のジェネリックを実装する人は、最初にStepanovの「ElementsofProgramming」を数回読む必要があると思います。 それは多くのNotInventedHereの問題と車輪の再発明を回避するでしょう。 「C ++ Concepts」と「HaskellTypeclasses」がジェネリックスを実行する正しい方法である理由を明確にする必要があることを読んだ後。

この問題は再びアクティブになっているようです
これがストローマン提案の遊び場です
https://go-li.github.io/test.html
ここからデモプログラムを貼り付けるだけです
https://github.com/go-li/demo

この単一のパラメータを評価していただきありがとうございます
関数ジェネリック。

ハッキングされたgccgoを維持し、
このプロジェクトはあなたなしでは不可能だったので、私たちは
貢献したかった。

また、あなたが採用するジェネリック医薬品を楽しみにしています。素晴らしい仕事を続けてください！

@anlhordこれに関する実装の詳細はどこにありますか？ 構文についてどこで読むことができますか？ 何が実装されていますか？ 何が実装されていませんか？ この実装の仕様は何ですか？ それの長所と短所は何ですか？

遊び場のリンクには、これの最悪の例が含まれています。

package main

import "fmt"

func main() {
    fmt.Println("Hello, playground")
}

そのコードは、それを使用する方法と私が何をテストできるかについて何も教えてくれません。

それらを改善できれば、あなたの提案が何であるか、そしてそれが以前のものとどのように比較されるかをよりよく理解するのに役立ちます/ここで提起された他のポイントがそれにどのように適用されるかどうかを確認してください。

これがコメントの問題を理解するのに役立つことを願っています。

@johoは書いた：

アプローチを評価するためのガイダンスとして、学術文献に価値はありますか？

このトピックについて私が読んだ唯一の論文は、開発者はジェネリック型の恩恵を受けていますか？ （ペイウォール申し訳ありませんが、PDFダウンロードへの道をグーグルで検索するかもしれません）

したがって、実験の保守的な解釈
ジェネリック型はトレードオフと見なすことができるということです
肯定的なドキュメントの特徴と
負の拡張特性。

Goにはすでにタイプクラスのようなinterface （明示的なTジェネリック型パラメーターなし）があるため、OOPとサブクラス化（JavaやC ++のクラスなど）は両方とも真剣に考慮されないと思います。コピーしないものとして引用され、多くの人がアンチパターンであると主張しているためです。 アップスレッド私はその議論のいくつかにリンクしました。 誰かが興味を持っているなら、私たちはその分析をより深く掘り下げることができます。

upthreadで言及されているGenusシステムなどの新しい研究はまだ研究していません。 Scalaに関する苦情のために、非常に多くのパラダイム（たとえば、サブクラス化、多重継承、OOP、トレイト線形化、 implicit 、型クラス、抽象型など）を混合しようとする「キッチンシンク」システムに警戒しています。実際には非常に多くのコーナーケースがありますが、おそらくそれはScala 3（別名DottyとDOT計算）で改善されるでしょう。 彼らの比較表が実験的なScala3と比較しているのか、それとも現在のバージョンのScalaと比較しているのか知りたいですか？

つまり、残っているのは、実証済みの汎用システムの観点から見たMLファンクターとHaskell型クラスであり、OOP +サブクラス化と比較して拡張性と柔軟性が大幅に向上しています。

私は@keeanのプライベートディスカッションのいくつかを書き留め、MLファンクターモジュールと型クラスについて話しました。 ハイライトは次のようです。

• typeclasses _model a algebra_ （ただし、チェックされた公理なし）で、各インターフェースの各データ型を一方向にのみ実装します。 したがって、呼び出しサイトで注釈を付けずに、コンパイラによる実装の暗黙的な選択を可能にします。

• アプリケーションファンクターには参照透過性がありますが、ジェネレーティブファンクターはインスタンス化ごとに新しいインスタンスを作成します。つまり、初期化順序は不変ではありません。

• MLファンクターは、型クラスよりも強力で柔軟性がありますが、アノテーションが増え、コーナーケースの相互作用が増える可能性があります。 また、 @ keeanによると、より複雑な型システムである依存型（関連する型）が必要です。 @keeanは、 Stepanovの_代数としての一般性の表現_と型クラスは十分に強力で柔軟性があると考えているため、（Haskellと現在はRustで）十分に証明された最先端の一般性のスイートスポットのようです。 ただし、公理は型クラスによって強制されません。

• O（log n）を持つことが知られている不変性またはコピー（異種の拡張性が採用されている場合のみ）が必要ですが、型クラスを持つ異種コンテナーのユニオンを追加して、式の問題の別の軸に沿って拡張することを提案しました抑制されていない可変の非定常性と比較した場合の速度

@larsthは書いた：

1つ以上の実験的なトランスパイラー（GoジェネリックソースコードからGo 1.xyソースコードコンパイラー）があると面白いかもしれません。

_{PS Goがこのような洗練されたタイピングシステムを採用するかどうかは疑問ですが、以前の投稿で述べたように、既存のGo構文へのトランスパイラーを検討しています（下部の編集を参照）。 そして、これらの非常に望ましいGo機能とともに堅牢な汎用システムが必要です。 Goの型クラスジェネリックは私が欲しいもののようです。}

@bcmillsは、汎用性のためのコンパイル時関数に関する彼の提案について次のように書いています。

同じ議論がGoAPIで具体的な型ではなくinterface型をエクスポートすることを提唱していたと聞きましたが、その逆がより一般的であることがわかりました。時期尚早の抽象化は型を過剰に制約し、APIの拡張を妨げます。 （そのような例の1つについては、＃19584を参照してください。）この議論の行に依存したい場合は、いくつかの具体的な例を提供する必要があると思います。

型システムの抽象化は必然的にある程度の自由度を放棄することは確かに真実であり、時には「安全でない」（つまり、静的にチェックされた抽象化に違反する）という制約から抜け出すことがありますが、それは簡潔に注釈が付けられた不変条件を使用したモジュラーデカップリング。

汎用性のあるシステムを設計する場合、特にGoのコア哲学を考慮に入れる場合（たとえば、平均的なプログラマーが優先される場合）、主要な目標の1つとしてエコシステムの規則性と予測可能性を高めたいと考えています。

最小電力の原則が適用されます。 汎用性のためのコンパイル時関数の「隠された」不変条件の能力/柔軟性は、たとえばエコシステムのソースコードの可読性に害を及ぼす能力と比較検討する必要があります（ここで、モジュール式デカップリングは、リーダーが特定のモジュール/パッケージを理解するために、暗黙の推移的な依存関係のために、潜在的に無制限の量のコードを読み取る必要はありません！）。 タイプクラス実装インスタンスの暗黙的な解決には、代数がに準拠していない場合にこの問題があります。

もちろんですが、ジェネリックプログラミングメカニズムに関係なく、Goの多くの暗黙の制約についてはすでに当てはまります。

たとえば、関数はインターフェイスタイプのパラメータを受け取り、最初にそのメソッドを順番に呼び出す場合があります。 その関数が後で（追加のゴルーチンを生成することによって）それらのメソッドを同時に呼び出すように変更された場合、「同時使用に対して安全でなければならない」という制約は型システムに反映されません。

しかし、afaik Goは、これらの効果をモジュール化するための抽象化を設計しようとはしませんでした。 Rustにはそのような抽象化があります（これは、ピタ/ツリス/一部の/ほとんどのユースケースを制限するのはやり過ぎだと思いますが、シングルスレッドモデルの抽象化が簡単であると主張していますが、残念ながら、Goはすべての生成されたゴルーチンを同じスレッドに制限することをサポートしていません） 。 また、Haskellは、参照透過性のために純粋関数を適用するため、効果を一元的に制御する必要があります。

@alercahは書いた：

推論された制約の最大の欠点は、型を完全に理解していなくても、制約を導入する方法で型を簡単に使用できることだと思います。 最良の場合、これはユーザーが予期しないコンパイル時の失敗に遭遇する可能性があることを意味しますが、最悪の場合、これは誤って新しい制約を導入することによってコンシューマーのパッケージを壊す可能性があることを意味します。 明示的に指定された制約はこれを回避します。

同意しました。 タイプの不変条件に明示的に注釈が付けられていないため、他のモジュールのコードを密かに解読できることは、ひどく陰湿です。

@andrewcmyersは書いた：

明確にするために、gen、cpp、gofmt -r、または他のマクロ/テンプレートツールで行われるかどうかにかかわらず、マクロスタイルのコード生成は、標準化されている場合でも、ジェネリックの問題に対する優れた解決策であるとは考えていません。 C ++テンプレートと同じ問題があります。コードの膨張、モジュラー型チェックの欠如、デバッグの難しさです。 当然のことながら、他のジェネリックコードの観点からジェネリックコードを構築し始めると、さらに悪化します。 私の考えでは、利点は限られています。Goコンパイラの作成者の生活を比較的シンプルに保ち、効率的なコードを生成します。命令キャッシュのプレッシャーがない限り、最近のソフトウェアでは頻繁に発生します。

@keeanはあなたに同意しているようです。

@ shelby3コメントありがとうございます。 次回は、ドキュメント自体で直接コメント/編集を行うことができますか？ 修正が必要な箇所を追跡するのが簡単で、すべてのメモが適切に応答するようにするのも簡単です。

概要セクションは、Javaがインスタンスのボクシング参照を普遍的に使用していることを示唆しているようです...

包括的なリストではないことを明確にするためにコメントを追加しました。 これは主に、人々がさまざまなトレードオフの要点を理解できるようにするためにあります。 さまざまなアプローチの完全なリストを以下に示します。

一般的な構造は、あらゆる用途の機能を蓄積する傾向があるため、コンパイル時間の増加やコードの膨張、またはよりスマートなリンカーの必要性が生じます。
型クラスの場合、これは当てはまらないか、それほど問題にはなりません。インターフェイスは、それらのインターフェイスを使用する関数に提供されるデータ型に対してのみ実装する必要があるためです。 タイプクラスは、すべてのデータ型をクラス実装のメソッドにバインドするOOPとは異なり、実装のインターフェイスへの遅延バインディングに関するものです。

その声明は、長期的に一般的なデータ構造に何が起こるかについてです。 言い換えれば、一般的なデータ構造は、多くの場合、さまざまな目的のために複数の小さな実装を持つのではなく、すべてのさまざまな用途を収集することになります。 例として、 https：//www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.htmlを見てください。

重要なのは、優れた「ジェネリックソリューション」を作成するには、「機械設計」と「柔軟性」だけでは不十分であるということです。 また、適切な指示、使用方法と回避方法、および人々が最終的にどのように使用するかを検討する必要があります。

一般的な構造とそれらを操作するAPIは、専用のAPIよりも抽象的である傾向があります...

この懸念を大幅に改善すると私が思う反論は、本質的に同じ遺伝的アルゴリズムの無制限の数の特殊なケースの再実装を学習することの認知的負担は無制限であるということです...

多くの同様のAPIの認知的負荷に関するメモを追加しました。

特別な場合の再実装は、実際には無制限ではありません。 固定数のスペシャライゼーションのみが表示されます。

これは有効な詐欺ではありません。

いくつかの点に異議を唱えるかもしれませんし、私はそれらのかなりの数にある程度異議を唱えますが、私は彼らの視点を理解し、人々が日々直面している問題を理解しようとしています。 このドキュメントの目的は、「誰かにとって何かがどれほど迷惑か」を判断することではなく、さまざまな意見を収集することです。

ただし、フォーラムでの抽象的で促進された問題は、理解が構築されていないと意味のないおしゃべりに陥る傾向があるため、このドキュメントは「現実世界の問題に追跡可能な問題」というスタンスをとっています。

ここで実際に得ているのは、言語の規則性と汎用APIの助けであり、それを損なうものではありません。

実際には、このスタイルの最適化が必要になるのは、1％未満の場合のみです。

代替ソリューション：

代替ソリューションは、ジェネリック医薬品の代わりになるものではありません。 しかし、むしろ、さまざまな種類の問題に対する潜在的な解決策のリストです。

パッケージテンプレート

私は間違っているかもしれませんが、これは完全には正しくないようです。 MLファンクター（FPファンクターと混同しないでください）は、タイプパラメーター化されたままの出力を返すこともできます。

より明確な表現を提供し、必要に応じて2つの異なるアプローチに分割できますか？

@egonelbreも返信してくれてありがとう。自分の考えをさらに明確にする必要がある点を知ることができます。

次回は、ドキュメント自体で直接コメント/編集を行うことができますか？

申し訳ありませんが、準拠できればと思いますが、Googleドキュメントのディスカッション機能を使用したことがなく、学習する時間がありません。また、Githubでのディスカッションにリンクして、後で参照できるようにしたいと考えています。

例として、https：//www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.htmlを見てください。

Scalaコレクションライブラリのデザインは、以前の主要なチームメンバーの1人を含む多くの人々から批判されました。 LtUに投稿されたコメントは代表的なものです。 これに対処するために、このスレッドの以前の投稿の1つに以下を追加したことに注意してください。

Scalaに関する苦情のために、非常に多くのパラダイム（たとえば、サブクラス化、多重継承、OOP、トレイト線形化、 implicit 、型クラス、抽象型など）を混合しようとする「キッチンシンク」システムに警戒しています。実際には非常に多くのコーナーケースがありますが、おそらくそれはScala 3（別名DottyとDOT計算）で改善されるでしょう。

Scalaのコレクションライブラリは、ポリモーフィズムの型クラスのみを持つPL用に作成されたライブラリを代表するものではないと思います。 不公平なことに、Scalaコレクションは、複雑な階層を引き起こした継承のアンチパターンを、複雑な予算を爆発させたCanBuildFromなどのimplicitヘルパーと組み合わせて採用しています。 そして、@ keeanの主張が、Stepanovの_Elements of Programming_が代数であることに固執すれば、エレガントなコレクションライブラリを作成できると思います。 これは、これも数学に基づいた、functor（FP）ベースのコレクションライブラリ（つまり、Haskellをコピーしない）に私が見た最初の選択肢でした。 これを実際に見てみたいと思います。これが、新しいPLの設計について彼と協力/話し合っている理由の1つです。 そしてこの瞬間の時点で、私はその言語を最初にGoにトランスパイルすることを計画しています（私は何年もそうすることを避ける方法を見つけようとしてきましたが）。 ですから、すぐに実験して、それがどのように機能するかを確認できるようになることを願っています。

私の認識では、Goコミュニティ/哲学は、失敗した実験で言語を急いで汚染するよりも、実際に機能するものを確認し、後で証明されたらそれを採用するのを待つほうがよいと考えています。 繰り返しになりますが、これらの抽象的な主張はすべてそれほど建設的ではありません（おそらくPL設計理論家を除く）。 また、委員会によって首尾一貫したジェネリックシステムを設計することはおそらくあり得ないことです。

また、適切な指示、使用方法と回避方法、および人々が最終的にどのように使用するかを検討する必要があります。

そして、同じ言語でプログラマーが利用できる非常に多くの異なるパラダイムを混在させないようにするのに役立つと思います。 それは明らかに必要ではありません（ @keeanと私はその主張を証明する必要があります）。 私たちは両方とも、複雑さの予算は有限であり、含まれている機能と同じくらい重要なのはPLから除外するものであるという哲学に帰するものだと思います。

ただし、フォーラムでの抽象的で促進された問題は、理解が構築されていないと意味のないおしゃべりに陥る傾向があるため、このドキュメントは「現実世界の問題に追跡可能な問題」というスタンスをとっています。

同意しました。 また、誰もが抽象的なポイントに従うことも困難です。 悪魔は細部に宿り、実際の結果は野生にあります。

実際には、このスタイルの最適化が必要になるのは、1％未満の場合のみです。

Goにはすでに汎用性のためのinterfaceがあるため、呼び出しサイトによって提供されるインターフェイスのインスタンスのタイプTでパラメトリックポリモーフィズムを必要としない場合を処理できます。

私はどこかで読んだと思います、多分それはアップスレッドでした、実際にGoの標準ライブラリは最新のイディオムの最適な使用の矛盾に苦しんでいるという議論。 私はまだGoの経験がないので、それが本当かどうかはわかりません。 私が指摘しているのは、選択したジェネリックパラダイムがすべてのライブラリに感染するということです。 したがって、現時点では、ジェネリックスの必要性を回避するイディオムにはすでに慣性があるため、コードの1％のみがそれを必要とすると主張できます。

あなたは正しいかもしれません。 また、特定の言語機能をどれだけ使用するかについても懐疑的です。 調べるための実験が私が進む方法だと思います。 PL設計は反復プロセスであり、問​​題は、発生する慣性との戦いでプロセスの反復を困難にすることです。 ですから、Rob Pikeは、アイデアを実験してテストするためのプログラムのコードを書くプログラム（つまり、生成ツールとトランスパイラーを書くことを意味します）を書くことを提案しているビデオで正しいと思います。

特定の機能セットが現在Goにある機能よりも実際に優れている（そして、できれば使用の人気もある）ことを示すことができれば、それらをGoに追加することに関するコンセンサスフォームを見ることができます。 他の人にも、Goにトランスパイルする実験システムを作成することをお勧めします。

より明確な表現を提供し、必要に応じて2つの異なるアプローチに分割できますか？

Goに過度に単純化されたテンプレート機能を入れようとする試みを思いとどまらせ、それがジェネリックであると主張したい人に私の声を加えます。 IOW、私は、悪い慣性になることのない適切に機能するジェネリックシステムは、ジェネリックの過度に単純化された設計を持ちたいという願望と根本的に両立しないと思います。 ジェネリックシステムであるAfaikには、よく考えられ、十分に証明された全体的な設計が必要です。 @larsthが書いたことを反映して、真剣な提案をしている人には、最初にトランスパイラーを構築し（または、gccgoフロントエンドのフォークに実装して）、次に提案を試してみることをお勧めします。 @ianlancetaylorが悪い慣性の汚染がGoに追加されるとは思わなかったというアップスレッドを読むように勧められました。 パッケージレベルのパラメータ化の提案に関する私の具体的な苦情については、誰がそれを提案しているのかについての私の提案です。私たち全員が使用できるコンパイラを作成するかどうかを検討してください。そうすれば、私たち全員が好きなものと嫌いなものの例について話すことができます。それについて好きです。 そうでなければ、抽象的に説明されている提案を正しく理解していない可能性があるため、私たちはお互いを超えて話し合っています。 パラメータ化されたパッケージを、パラメータ化された別のパッケージで再利用する方法がわからないため、提案を理解してはなりません。 IOW、パッケージがパラメータを受け取る場合、パラメータを使用して他のパッケージもインスタンス化する必要があります。 しかし、提案は、パラメータ化されたパッケージをインスタンス化する唯一の方法は、型パラメータではなく、具象型を使用することであると述べているようでした。

お詫び申し上げます。 私が誤解されていないことを確認したい。

@ shelby3ああ、それから私は最初の苦情を誤解しました。 まず、「ジェネリックスアプローチ」のセクションは具体的な提案ではないことを明確にする必要があります。 それらはアプローチであり、言い換えれば、具体的なジェネリックスアプローチで採用する可能性のあるより大きな設計上の決定です。 ただし、グループ化は、既存の実装または具体的/非公式の提案によって強く動機付けられています。 また、そのリストにはまだ少なくとも5つの大きなアイデアが欠けていると思います。

「パッケージテンプレート」アプローチには、2つのバリエーションがあります（ドキュメント内のリンクされたディスカッションを参照してください）。

1. 「インターフェース」ベースの汎用パッケージ、
2. 明示的に汎用パッケージ。

1.の場合、汎用パッケージで特別なことを行う必要はありません。たとえば、現在のcontainer/ringは特殊化に使用できるようになります。 ここで「特殊化」を想像してみてください。パッケージ内のインターフェイスのすべてのインスタンスを具象型に置き換えます（循環インポートを無視します）。 そのパッケージ自体が別のパッケージを特殊化する場合、「インターフェース」を特殊化として使用できます。したがって、この使用も特殊化されます。

2.の場合、2つの方法でそれらを見ることができます。 1つは、インポートごとの再帰的な具体的な特殊化です。テンプレート/マクロ化と同様に、「部分的に適用されたパッケージ」はありません。 もちろん、機能面から見ると、汎用パッケージはパラメーターを含む部分的なものであり、それを特殊化することもできます。

したがって、はい、あるパラメータ化されたパッケージを別のパッケージで使用できます。

@larsthが書いたことを反映して、真剣な提案をしている人には、最初にトランスパイラーを構築し（または、gccgoフロントエンドのフォークに実装し）、次に提案を試して、制限をよりよく理解できるようにすることをお勧めします。

これがそのアプローチに明示的に向けられたものではないことは知っていますが、アイデアをテストするための4つの異なるプロトタイプがあります。 もちろん、それらは完全なトランスパイラーではありませんが、いくつかのアイデアをテストするには十分です。 つまり、誰かが「別のパラメータ化されたパッケージを使用する」ケースを実装したかどうかはわかりません。

パラメータ化されたパッケージはMLモジュールによく似ています（MLファンクタはパラメータが他のパッケージである可能性があります）。 これらが「適用的」または「生成的」に機能する方法は2つあります。 適用可能なファンクターは、値またはタイプエイリアスのようなものです。 生成ファンクタを構築する必要があり、各インスタンスは異なります。 これについて考える別の方法は、パッケージが適用可能であるためには、純粋でなければならないことです（つまり、パッケージレベルで可変変数はありません）。 パッケージレベルに状態がある場合、その状態を初期化する必要があるため、生成的である必要があります。また、生成的である必要がある他のパッケージにパラメータとして実際に渡す生成的パッケージの「インスタンス」が重要です。 たとえば、Adaパッケージは生成的です。

生成パッケージアプローチの問題は、パラメータを使用してパッケージをインスタンス化するボイラープレートが大量に作成されることです。 Adaジェネリックを見て、これがどのように見えるかを確認できます。

型クラスは、関数でのみ使用される型に基づいて型クラスを暗黙的に選択することにより、この定型文を回避します。 型クラスは、多重ディスパッチによる制約付きオーバーロードと見なすこともできます。オーバーロードの解決は、ほとんどの場合、コンパイル時に静的に発生します。ただし、ポリモーフィック再帰と存在型（本質的にはキャストアウトできないバリアントであり、使用できるのはバリアントが確認するインターフェース）。

適用可能なファンクターは、値またはタイプエイリアスのようなものです。 生成ファンクタを構築する必要があり、各インスタンスは異なります。 これについて考える別の方法は、パッケージが適用可能であるためには、純粋でなければならないことです（つまり、パッケージレベルで可変変数はありません）。 パッケージレベルに状態がある場合、その状態を初期化する必要があるため、生成的である必要があります。また、生成的である必要がある他のパッケージにパラメータとして実際に渡す生成的パッケージの「インスタンス」が重要です。 たとえば、Adaパッケージは生成的です。

正確な用語をありがとうございます。これらのアイデアをドキュメントに統合する方法を考える必要があります。

また、「アプリケーション型ファンクター」と「生成型ファンクター」のアプローチの中間にある意味で、「生成されたパッケージの自動タイプエイリアス」を使用できなかった理由もわかりません。 明らかに、パッケージに何らかの形の状態が含まれていると、デバッグと理解が複雑になる可能性があります。

生成パッケージアプローチの問題は、パラメータを使用してパッケージをインスタンス化するボイラープレートが大量に作成されることです。 Adaジェネリックを見て、これがどのように見えるかを確認できます。

私が見る限り、C ++テンプレートよりも定型文は少なくなりますが、型クラスよりは多くなります。 問題を実証するAdaの優れた実世界のプログラムはありますか？ _（実際には、誰かが本番環境で使用している/使用していたコードを意味します。）_

確かに、私のAdaゴーボードを見てください： https ：//github.com/keean/Go-Board-Ada/blob/master/go.adb

これは本番環境のかなり緩い定義ですが、コードは最適化されており、C ++バージョンとそのオープンソースと同様に機能し、アルゴリズムは数年にわたって改良されています。 C ++バージョンも見ることができます： https ：//github.com/keean/Go-Board/blob/master/go.cpp

これは、AdaジェネリックがC ++テンプレートよりも優れたソリューションであることを示しています（ただし、それは難しいことではありません）。一方、参照を返す際の制限により、Adaのデータ構造に高速アクセスすることは困難です。 。

命令型言語のパッケージジェネリックシステムを見たいのなら、Adaが一番いいと思います。 彼らがマルチパラダイムに行き、すべてのOOのものをAdaに追加することを決めたのは残念です。 Adaは拡張されたPascalであり、Pascalは小さくてエレガントな言語でした。 PascalとAdaのジェネリックスはまだかなり小さな言語でしたが、私の意見でははるかに優れていたでしょう。 Adaの焦点がオブジェクト指向アプローチに移ったため、ジェネリックで同じことを行う方法の良いドキュメントと例を見つけるのは難しいようです。

型クラスにはいくつかの利点があると思いますが、Adaスタイルのジェネリックスと一緒に暮らすことができます。Adaをより広く使用することを妨げるいくつかの問題があります。値/オブジェクトが間違っていると思います（これを正しく行う言語はほとんどないと思いますが、 「C」は唯一のものの1つです）、ポインター（アクセス変数）を操作したり、セーフポインターの抽象化を作成したりすることは困難であり、ランタイムポリモーフィズムを備えたパッケージを使用する方法を提供しません（オブジェクトモデルを提供します）このためですが、パッケージを使用してランタイムポリモーフィズムを実現する方法を見つけるのではなく、まったく新しいパラダイムを追加します）。

ランタイムポリモーフィズムの解決策は、パッケージをファーストクラスにして、パッケージ署名のインスタンスを関数の引数として渡すことができるようにすることです。これには、残念ながら依存型が必要です（Scalaの依存オブジェクト型で行われた作業を参照して、それらが作成した混乱を解消してください。元の型システム）。

パッケージジェネリックは機能すると思いますが、すべてのエッジケースに対処するのにAdaは数十年かかりました。そこで、プロダクションジェネリックシステムを調べて、プロダクションでどのような改良が行われたかを確認します。 ただし、パッケージはファーストクラスではなく、ランタイムポリモーフィズムでは使用できないため、Adaはまだ不十分であり、これに対処する必要があります。

@keeanは書いた：

個人的には、ランタイムリフレクションは誤った機能だと思いますが、それは私だけです...誰かが興味を持っているのなら、その理由を説明できます。

型消去は「無料の定理」を可能にしますが、これは実際的な意味合いがあります。 書き込み可能（そして命令型コードとの一時的な関係のために読み取り可能でさえありますか？）ランタイムリフレクションは、コードの参照透過性を保証することを不可能にします。したがって、特定のコンパイラーの最適化は不可能であり、タイプセーフなモナドは不可能です。 Rustにはまだ不変性機能さえないことに気づきました。 OTOH、リフレクションは、静的に型付けできなかった場合には不可能だった他の最適化を可能にします。

私はアップスレッドについても述べました：

これが、ジェネリックスが追加されたGoのスーパーセットからトランスパイルするコンパイラーがGoコードとして出力するものです。 しかし、ラッピングは、パッケージなどの描写に基づいていません。これは、すでに述べた構成可能性に欠けているためです。 優れたコンポーザブルジェネリック型システムへの近道はないということを指摘してください。 正しく行うか、何もしないかのどちらかです。これは、実際にはジェネリックではないコンポーザブルではないハックを追加すると、最終的にはパッチワークの半ばのジェネリックのクラスターファック慣性とコーナーケースの不規則性、およびGoエコシステムコードを作成する回避策が作成されるためです。理解できない。

@keeanは書いた：

[…]パッケージが適用可能であるためには、それは純粋でなければなりません（つまり、パッケージレベルで可変変数はありません）

また、不変変数を初期化するために不純な関数を使用することはできません。

@egonelbreは書いた：

したがって、はい、あるパラメータ化されたパッケージを別のパッケージで使用できます。

どうやら私が念頭に置いていたのは、「ファーストクラスのパラメーター化されたパッケージ」と、 @ keeanが後で言及したそれに見合ったランタイム（別名動的）ポリモーフィズムでした。パラメーター化されたパッケージは、型クラスまたはOOPの代わりに提案されたと推測したからです。

編集：ただし、「ファーストクラス」モジュールには2つの意味があります。SuccessorMLやMixMLなどのファーストクラス値としてのモジュールと、 1MLなどのファーストクラスタイプのファーストクラス値としてのモジュールとの区別、および必要なトレードオフです。それらの間のモジュール再帰（すなわち混合）で。

@keeanは書いた：

ランタイムポリモーフィズムの解決策は、パッケージをファーストクラスにして、パッケージ署名のインスタンスを関数の引数として渡すことができるようにすることです。これには、残念ながら依存型が必要です（Scalaの依存オブジェクト型で行われた作業を参照して、それらが作成した混乱を解消してください。元の型システム）。

依存型とはどういう意味ですか？ （編集：彼は「値に依存しない」型付け、つまり「結果の型が[ランタイム？]引数[の型]に依存する関数」を意味していると思います）確かに、たとえばintの値には依存しませんIdrisなどのF-ing Modulesは、システム_FωでMLモジュールをモデル化するために「依存」型が絶対に必要なわけではないことを示しました。 @rossbergがすべての単形化要件を削除するためにタイピングモデルを再定式化したと仮定した場合、私は過度に単純化しましたか？

生成パッケージアプローチの問題は、ボイラープレートを大量に作成することです[…]
型クラスは、関数でのみ使用される型に基づいて型クラスを暗黙的に選択することにより、この定型文を回避します。

適用可能なMLファンクターを備えた定型文もありませんか？ 型クラスの既知の統一はなく、型クラス実装インスタンスのグローバル一意性基準の固有の反モジュラリティを防ぐために必要な制限を導入することなく簡潔さを保持するMLファンクター（モジュール）があります。

タイプクラスは、各タイプを1つの方法でのみ実装できます。それ以外の場合は、制限を克服するためにnewtypeラッパーボイラープレートが必要です。 アルゴリズムを実装する複数の方法の別の例を次に示します。 Afaics、 @ keeanは、型クラスの並べ替えの例でこの制限を回避するために、明示的に選択されたRelationで暗黙の選択をオーバーライドし、値型で一般的に異なる関係に名前を付けるためにdata型をラップすることを採用しましたが、私は疑っていますそのような戦術がモジュール性のすべての変形に一般的であるかどうか。 ただし、より一般化されたソリューション（孤立する可能性のある実装にデフォルト以外の方法を採用することで、孤立した解決のために提案されたバージョン管理の改善として、孤立した制限と組み合わされる可能性のあるグローバルな一意性のモジュール性の問題を改善するのに役立ちます）すべての型クラスinterfaceに暗黙的に追加の型パラメーターがあります。これは、指定されていない場合はデフォルトで通常の暗黙的な一致になりますが、指定されている場合（または指定されていない場合は他の²と一致しません）、同じ値を持つ実装を選択しますカスタム値のコンマ区切りリスト内（したがって、これは特定のimplementインスタンスに名前を付けるよりも一般化されたモジュラーマッチングです）。 カンマ区切りのリストは、2つの直交する特殊化がある場合など、実装を複数の自由度で区別できるようにするためのものです。 必要なデフォルト以外の特殊化は、関数宣言または呼び出しサイトのいずれかで指定できます。 コールサイトで、たとえばf<non-default>(…) 。

では、型クラスがある場合、なぜパラメーター化されたモジュールが必要になるのでしょうか。 （←クリックするための重要なリンク）置換のみのAfaicsは、その目的で型クラスを再利用することは、たとえば、パッケージモジュールが複数のファイルにまたがることができ、追加のボイラープレートなしでモジュールをスコープに入れます。 したがって、おそらく_構文のみ_置換のみ（ファーストクラスではない）のパッケージパラメータ化は、関数レベルで後で型クラスを追加する場合に、機能との互換性と重複のない状態を維持しながら、モジュールレベルの汎用性に対処できる合理的な最初のステップです。汎用性。 マクロがたとえば型指定されているのか、単に構文（別名「プリプロセッサ」）置換であるのかという問題があります。 タイプされた場合、モジュールはタイプクラスの機能を複製します。これは、PLの重複するパラダイム/概念と、重複の相互作用による潜在的なコーナーケース（MLファンクターとタイプクラスの両方を提供しようとする場合など）の両方の観点から望ましくありません。 ）。 エクスポートされた署名を変更しないモジュール内のカプセル化された実装への変更は、モジュールのコンシューマーに互換性を持たせることができないため、型付きモジュールはよりモジュール化されます（前述の型クラスの重複する実装インスタンスの反モジュール性の問題を除く）。 これに関する@keeanの考えを読むことに興味があります。

[…]ポリモーフィック再帰と実存型（本質的にはキャストアウトできないバリアントであり、バリアントが確認するインターフェースのみを使用できます）を除いて。

他の読者を助けるため。 「ポリモーフィック再帰」とは、上位の型を指すと思います。たとえば、実行時に設定されたパラメーター化されたコールバックでは、コンパイル時にコールバック関数の本体が不明であるため、コンパイラーがコールバック関数の本体をモノモーフィングできません。 存在型は、前に述べたように、Rustの特性オブジェクトと同等です。これは、仮想継承をサブクラス化するclassよりも、式の問題で後でバインディングを使用して異種コンテナーを取得する1つの方法ですが、式の拡張にはそれほどオープンではありません。 O（log n）のパフォーマンスコストを持つ不変のデータ構造またはコピー³の和集合としての問題。

¹_{上記の例ではHKTを必要としません。これは、 SETがelemを必要としないためです。タイプは、ジェネリック型setの型パラメーターです。つまり、 set<elem>ではありません。}

²_{ただし、デフォルト以外の実装が複数存在し、デフォルトの実装がない場合、選択があいまいになるため、コンパイラはエラーを生成する必要があります。}

³_{不変のデータ構造での変更は、データ構造が単一リンクリストなどの履歴を分離するのに十分スマートである場合、必ずしもデータ構造全体をコピーする必要はないことに注意してください。}

func pick(a CollectionOfT, count uint) []Tを実装することは、ジェネリックスの良い例のアプリケーションです（https://github.com/golang/go/issues/23717から）：

// pick returns a slice (len = n) of pseudorandomly chosen elements 
// in unspecified order from c which is an array, slice, or map.
for i, e := range pick(c, n) {

ここでのinterface {}アプローチは複雑です。

この問題について、C ++テンプレートアプローチの主な問題の1つは、コンパイル時のメタプログラミングのメカニズムとしての過負荷解決への依存であると何度かコメントしました。

ハーブサッターも同じ結論に達したようです。C++でのコンパイル時プログラミングに関する興味深い提案があります。

これには、Go reflectパッケージと、 Goのコンパイル時関数に関する以前の提案の両方に共通する要素がいくつかあります。

こんにちは。
Goの制約付きのジェネリックスの提案を書きました。 ここで読むことができます。 おそらく、15292のドキュメントとして追加できます。これは主に制約に関するものであり、GoのTaylors TypeParametersの修正として読み取られます。
これは、Goで「タイプセーフ」ジェネリックを実行する（私が信じる）実行可能な方法の例として意図されています-うまくいけば、この議論に何かを追加することができます。
私はこの非常に長いスレッド（のほとんど）を読んでいますが、その中のすべてのリンクをたどっていないので、他の人が同様の提案をした可能性があることに注意してください。 その場合は、お詫び申し上げます。

br。 Chr。

構文bikeshedding：

constraint[T] Array {
    :[#]T
}

になり得る

type [T] Array constraint {
    _ [...]T
}

Go tomeのように見えます。 :-)

ここにいくつかの要素があります。

1つは、 :を_に置き換え、 #を...に置き換えることです。
よろしければそうすることができると思います。

もう1つは、 constraint[T] Arrayをtype[T] Array constraintに置き換えることです。
これは、制約が型であることを示しているように思われますが、これは正しくないと思います。 正式には、制約はすべてのタイプのセットに対する_述語_です。 タイプのセットからセット{ true 、 false }へのマッピング。
または、必要に応じて、制約を単に_一連の_型と考えることもできます。
_a_タイプではありません。

br。 Chr。

constraintが単なるinterfaceではないのはなぜですか？

type [T io.Writer] List struct { 
    element T; 
    next *List[T];
}

インターフェースは、次の提案の制約としてもう少し便利です。＃23796これは、提案自体にもメリットをもたらします。

また、合計型の提案が何らかの形で受け入れられる場合（＃19412）、それらを使用して型を制約する必要があります。

制約キーワードだと思いますが、大きな制約を繰り返さないようにし、ぼんやりによるエラーを防ぐために、そのようなものを追加する必要があります。

最後に、バイクシェディングの部分については、過密を避けるために、定義の最後に制約をリストする必要があると思います（錆はここでは良い考えのようです）：

// similar to the map[T]... syntax
// also no constraint
type List[T] struct {
    element T
    next *List[T]
}

// with constraint
type List[T] struct {
    element T
    next *List[T]
} where T is io.Writer | encoding.BinaryMarshaler

type BigConstraint constraint {
     io.Writer
     SomeFunc() int
     AnotherFunc()
     AField int64
     StringField string
}


// with predefined constraint
type List[T, U] struct {
    element T
    val U
    next *List[T, U]
} where T is BigConstraint | encoding.BinaryMarshaler,
    U is io.Reader

@urandom ：インターフェイスを明示的にではなく暗黙的に実装することの大きな利点の1つだと思います。 このコメントの@surlykkeの提案は、精神的には他のGo構文にはるかに近いと思います。

@surlykke提案にこれらのいずれかに対する答えがある場合は、お詫び申し上げます。

ジェネリックスの使用は、組み込みのスタイル関数を許可することです。 これを使用して、アプリケーションレベルのlenをどのように実装しますか？ メモリレイアウトは許可された入力ごとに異なりますが、これはインターフェイスよりも優れていますか？

前述の「ピック」には、マップへのインデックス作成とスライスへのインデックス作成が異なるという同様の問題があります。 マップの場合、最初にスライスへの変換があった場合、同じピッキングコードを使用できますが、これはどのように行われますか？

コレクションは別の用途です：

// An unordered collection of comparable items.
type [T Comparable] Set []T

func (a Set) Diff(from Set) Set {
    // the implementation is the same as one with
    //     type Comparable interface { Equal(Comparable) bool }
    //     type Set []Comparable
}

// compile error
d := Set[int]{1, 2}.Diff(Set[string]{“abc”, “def”})

// Go 1, easier to read but runtime error
d := Set{1, 2}.Diff(Set{“abc”, “def”})

コレクションタイプの場合、読みやすさのトレードオフがあるため、これがGo1ジェネリックよりも大きな勝利であるとは確信していません。

タイプパラメータには何らかの形の制約が必要であることに同意します。 そうしないと、C ++テンプレートの間違いを繰り返すことになります。 問題は、制約をどの程度表現する必要があるかということです。

一方では、インターフェースを使用することもできます。 しかし、ご指摘のとおり、多くの有用なパターンをそのようにキャプチャすることはできません。

次に、一連の有用な制約を切り分けて、それらを表現するための新しい構文を提供しようとする、あなたのアイデアと同様のアイデアがあります。 さらに構文を追加するという問題は別として、どこで停止するかは明確ではありません。 ご指摘のとおり、提案には多くのパターンが含まれていますが、すべてではありません。

もう一方の極端な例は、このドキュメントで提案するアイデアです。 制約言語としてGoコード自体を使用します。 この方法で事実上すべての制約をキャプチャでき、新しい構文は必要ありません。

@jba
少し冗長です。 たぶん、Goがラムダ構文を持っていれば、もう少し口当たりが良くなるでしょう。 一方、解決しようとしている最大の問題は、型が何らかの演算子をサポートしているかどうかを確認することだと思われます。 Goにさまざまな演算子用の事前定義されたインターフェースがあれば、もっと簡単かもしれません。

func equal[T](x, y T) bool
    where T is runtime.Equitable {
    return x == y
}

func copyable[T](x, y []T) int {
    return copy(x, y)
}

またはこれらの線に沿った何か。

ビルトインの拡張に問題がある場合は、言語のアダプタタイプの作成方法に問題がある可能性があります。 たとえば、肥大化はsort.Interfaceに関連付けられていませんか？ https：//github.com/golang/go/issues/16721とsort.Sliceの背後にある理由全体ですか？
https://github.com/golang/go/issues/21670#issuecomment -325739411を見ると、 @ Sajmaniのインターフェイスリテラルのアイデアは、型パラメーターがビルトインで簡単に機能するために必要な要素である可能性があります。
イテレータの次の定義を見てください。

type [T] Iterator interface {
    Next() (elem T, done bool)
}

printが単にリストを反復処理してその内容を出力する関数である場合、次の例ではインターフェイスリテラルを使用して、 printの満足のいくインターフェイスを構築します。

func SliceIterator(slice []T) Iterator {
    i := 0
    return Iterator{
        Next: func() (elem int, done bool) {
            v := slice[i]
            if i+1 == len(slice) {
                return v, true
            }
            i++
            return v, false
        },
    }
}

func main() {
    arr := []int{1,2,3,4,5}
    // SliceIterator works for an arbitrary slice
    print(SliceIterator(arr))
}

インターフェイスを満たすことが唯一の責任である型をグローバルに宣言する場合は、すでにこれを行うことができます。 ただし、この関数からメソッドへの変換により、インターフェース（したがって「制約」）を簡単に満たすことができます。 単純なアダプター（ソートの「widgetsByName」など）でトップレベルの宣言を汚染することはありません。
このLinkedListの例に示されているように、ユーザー定義型もこの機能を利用できることは明らかです。

type ListNode struct {
    v string
    next *ListNode
}
func (l *ListNode) Iterator() Iterator {
    ptr := l
    return Iterator{
        Next: func() (elem int, done bool) {
            v := ptr.v
            if ptr.next == nil {
                return v, true
            }
            ptr = ptr.next
            return v, false
        },
    }
}

@ geovanisouza92 ：私が説明した制約は、インターフェース（フィールド、演算子）よりも表現力があります。 制約を導入する代わりにインターフェースを拡張することを簡単に検討しましたが、それはGoの既存の要素に非常に煩わしい変更になると思います。

@pciet 「アプリケーションレベル」の意味がよくわかりません。 Goにはlen関数が組み込まれており、配列、配列へのポインター、スライス、文字列、チャネルに適用できます。したがって、私の提案では、型パラメーターがこれらのいずれかを基になる型として持つように制約されている場合、 lenが適用される場合があります。

@pciet Comparable制約/インターフェイスを使用した例について。 （インターフェースバリアント）を定義する場合、以下に注意してください。

type Comparable interface { Equal(Comparable) bool }
type Set []Comparable

次に、 Comparableを実装するものをSetに入れることができます。 それを以下と比較してください：

constraint [T] Comparable { Equal(t T) bool }
type [T Comparable[T]] Set []T
...
type FooSet Set[Foo] // Where Foo satisfies constraint Comparable

ここで、タイプFooの値のみをFooSetに入れることができます。 それはより強い型安全性です。

@urandom繰り返しますが、私は次のファンではありません。

type MyConstraint constraint {....}

私は、制約がタイプであるとは思わないので。 また、私は絶対に許可しません：

var myVar MyConstraint

それは私には意味がありません。 制約が型ではないことを示すもう1つの兆候。

@urandomバイクシェディングについて：制約は型パラメーターのすぐ隣で宣言する必要があると思います。 次のように定義された通常の関数について考えてみます。

func MyFunc(i) {
     if (i>0) fmt.Println("It's positive")
} with i being an integer

これは左から右に読むことができませんでした。 代わりに、最初にfunc MyFunc(i)を読んで、それが関数定義であると判断します。 次に、最後にジャンプしてiが何であるかを理解してから、関数本体に戻る必要があります。 理想的ではありません、IMO。 そして、私は一般的な定義がどのように異なっているべきかわかりません。
しかし、明らかに、この議論は、Goに制約またはジェネリックを含めるべきかどうかに関する議論と直交しています。

@surlykke
タイプでなくても大丈夫です。 最も重要なことは、複数のタイプで参照できるように名前が付けられていることです。

関数の場合、rust構文に従うと、次のようになります。

func MyFunc[I](i I) int64
     where I is being an integer {
   return 42
}

したがって、関数の名前やそのパラメーターなどを非表示にすることはなく、ジェネリック型の制約を確認するために関数本体の最後に移動する必要はありません。

後世のための@surlykke 、あなたの提案を追加できる場所を見つけることができますか？
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

すべての提案を「まとめる」のに最適な場所です。

私が皆さんに提起するもう1つの質問は、ジェネリック型のさまざまなインスタンス化の特殊化をどのように処理するかということです。 type-params提案では、これを行う方法は、インスタンス化された型ごとに同じテンプレート関数を生成し、型パラメーターを型名に置き換えることです。 タイプごとに個別の機能を使用するには、タイプパラメータでタイプスイッチを実行します。

コンパイラが型パラメータの型スイッチを検出すると、アサーションごとに個別の実装を生成できると想定しても安全ですか？ または、アサートされた構造体のネストされた型パラメーターがコード生成のパラメトリックな側面を作成する可能性があるため、最適化にあまりにも関与していますか？

コンパイル時関数の提案では、これらの宣言はコンパイル時に生成されることがわかっているため、タイプスイッチによって実行時のコストが発生することはありません。

実用的なシナリオ：数学/ビットパッケージの場合を考えると、 uintXXごとに$ OnesCountを呼び出す型アサーションを実行すると、効率的なビット操作ライブラリを持つという点に勝るでしょう。 ただし、タイプアサーションが次のように変換された場合

func OnesCount(x T) int {
    switch x.(type) {
    case uint:
        // separate uint functionality...
    case uint8:
        // separate uint8 functionality...
    case uint16:
        // separate uint16 functionality...
    case uint32:
        // separate uint32 functionality...
    case uint64:
        // separate uint64 functionality...
    }
}

への呼び出し

var x uint8 = 255
bits.OnesCount(x)

次に、次の生成された関数を呼び出します（ここでは名前は重要ではありません）。

func $OnesCount_uint8(x uint8) {
    // separate uint8 functionality...
}

@jbaこれは興味深い提案ですが、私にとっては、パラメトリック関数自体の定義が通常、その制約を定義するのに十分であるという事実を主に強調しています。

「関数で使用される演算子」を制約として使用する場合、最初の関数で使用される演算子のサブセットを含む2番目の関数を作成することでどのような利点が得られますか？

@bcmills 1つは仕様で、もう1つは実装です。 これは静的型付けと同じ利点です。エラーを早期にキャッチできます。

実装がC ++テンプレートのような仕様である場合、実装に変更を加えると、依存関係が壊れる可能性があります。 それは、扶養家族が再コンパイルするずっと後になって初めて発見される可能性があり、発見者にはエラーメッセージを理解するためのコンテキストがありません。 同じパッケージの仕様で、ローカルで破損を検出できます。

@mandolyteどこに追加すればよいのかよくわかりません。「ジェネリックスアプローチ」の下にある「制約付きジェネリックス」という名前の段落でしょうか。
このドキュメントには、タイプパラメータの制約についてはあまり含まれていないようです。そのため、私の提案が言及される段落を追加すると、制約に対する他のアプローチもそこにリストされる可能性があります。

@surlykkeドキュメントの一般的なアプローチは、正しいと感じるものを変更することです。私はそれを受け入れ、組み込み、ドキュメントの残りの部分と一緒に整理しようとします。 ここにセクションを追加しました。 見逃したものを自由に追加してください。

@egonelbreそれはとてもいいです。 ありがとう！

@jba
私はあなたの提案が好きですが、それはゴランには重すぎると思います。 それは私にc ++の多くのテンプレートを思い出させます。 私が思う主な問題は、それを使って本当に複雑なコードを書くことができるということです。
制約された型のセットがオーバーラップするために2つのジェネリックインターフェイスインスタンスがオーバーラップするかどうかを判断するのは難しい作業であり、コンパイル時間が遅くなります。 コード生成についても同じです。

提案された制約は、外出先でより軽量だと思います。 私が聞いたところによると、型クラスとも呼ばれる制約は、言語の型システムに直交して実装できるということです。

関数の本体からの暗黙の制約を使用してはならないことに強く同意する必要があります。 これらは、C ++テンプレートの最も重大な誤動作の1つと広く見なされています。

• 制約は簡単にはわかりません。 godocは理論的にはすべての制約をドキュメントに列挙できますが、暗黙的に以外はソースコードに表示されません。
• そのため、予期しない方法で関数を使用しようとした場合にのみ表示される追加の制約を誤って含める可能性があります。 制約の明示的な指定を要求することにより、プログラマーは、導入している制約を正確に知る必要があります。
• それは、どの種類の制約がはるかにアドホックに許可されるかについての決定を行います。 たとえば、次の関数を定義することはできますか？ ここでのT、U、およびVの実際の制約は何ですか？ プログラマーに制約を明示的に指定するように要求する場合は、許可する種類の制約を控えめにします（ゆっくりと慎重に拡張します）。 とにかく保守的にしようとすると、このような関数のエラーメッセージをどのように表示しますか？ 「エラー：不正な制約を課しているため、uv（）をTに割り当てることができません」？

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

• 他のジェネリック関数でジェネリック関数を呼び出すと、上記の状況が悪化します。これは、書き込みまたは読み取りを行っている関数の制約を理解するために、すべての呼び出し先の制約を調べる必要があるためです。
• エラーメッセージは、制約のソースを見つけるのに十分な情報を提供しないか、関数の内部詳細をリークする必要があるため、デバッグは非常に困難になる可能性があります。 たとえば、 FにタイプTに関する要件があり、 Fの作成者がその要件がどこから来たのかを把握しようとしている場合、コンパイラはどのステートメントが制約を引き起こすかを正確に警告します（特に、一般的な呼び出し先からのものである場合）。 しかし、 Fのユーザーはその情報を望んでおらず、実際、それがエラーメッセージに含まれている場合、ユーザーからのエラーメッセージにFの実装の詳細がリークされています。ひどいユーザーエクスペリエンスです。

@alercah

たとえば、次の関数を定義することはできますか？

func[T, U, V] Foo(u U, v V) {
  var t T = u.v(V) + 1;
}

いいえ。$ Vは型であり、変数tは使用されていないため、 u.v(V)は構文エラーです。

ただし、この関数を定義することはできます。これは、意図したものである可能性があります。

func[T, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

ここでのT、U、およびVの実際の制約は何ですか？

• タイプVは制約されていません。
• u.vは単一の引数で呼び出されるため、タイプUには、 Vから割り当て可能な単一のパラメーターまたはあるタイプの変数を受け入れるメソッドvが必要です。タイプVの。
  
  
  
  • U.vは関数型のフィールドである可能性がありますが、おそらくそれはメソッドを意味するはずです。 ＃23796を参照してください。
  
  
• U.vによって返される型は、定数1が追加されるため、数値でなければなりません。
• u.v(…) + 1はタイプTの変数に割り当てられるため、 U.v Tに割り当て可能である必要があります。
• U.vの戻りタイプは数値であり、 Tに割り当てることができるため、タイプTは数値である必要があります。

（余談ですが、 UとVは、これらの型の引数が値で渡されるため、制約を「コピー可能」にする必要がありますが、既存の非ジェネリック型システムは強制しません。その制約もあります。それは別の提案の問題です。）

プログラマーに制約を明示的に指定するように要求する場合は、許可する種類の制約を控えめにします（ゆっくりと慎重に拡張します）。

はい、それは本当です。しかし、制約を省略することは、それらの制約が暗黙的であるかどうかにかかわらず、重大な欠陥になります。 IMO、制約のより重要な役割は、あいまいさを解決することです。 たとえば、上記の制約では、コンパイラはu.vを単一引数または可変個引数のいずれかのメソッドとしてインスタンス化する準備をする必要があります。

最も興味深い曖昧さは、構造体型と複合型の間で曖昧さを解消する必要があるリテラルで発生します。

func[T] Foo() (t T) {
    x := 42;
    t = T{x: "some string"}  // Is x an index, or a field name?
    _ = x
}

とにかく保守的にしようとすると、このような関数のエラーメッセージをどのように表示しますか？ 「エラー：不正な制約を課しているため、uv（）をTに割り当てることができません」？

この例では競合する制約が見られないため、何を求めているのかよくわかりません。 「違法な制約」とはどういう意味ですか？

エラーメッセージは、制約のソースを見つけるのに十分な情報を提供しないか、関数の内部詳細をリークする必要があるため、デバッグは非常に困難になる可能性があります。

関連するすべての制約を型システムで表現できるわけではありません（https://github.com/golang/go/issues/22876#issuecomment-347035323も参照）。 一部の制約は、実行時のパニックによって強制されます。 一部はレース検出器によって強制されます。 最も危険な制約は単に文書化されており、まったく検出されていません。

これらはすべて、ある程度「内部の詳細を漏らしている」。 （https://xkcd.com/1172/も参照してください。）

たとえば、[…] Fの作成者がその要件がどこから来たのかを理解しようとしている場合、どのステートメントが制約を生じさせるかを正確に警告するようにコンパイラーに要求します（特に一般的な呼び出し先からのものである場合）。 しかし、Fのユーザーはその情報を望んでいません[。]

多分？ これが、API作成者がHaskellやMLなどの型推論言語で型注釈を使用する方法ですが、一般に、非常にパラメトリックな（「高次」）型のうさぎの穴にもつながります。

たとえば、次の関数があるとします。

func [F, Arg, Result] InvokeAsync(f F, x Arg) (<-chan Result) {
    c := make(chan result, 1)
    go func() { c <- f(x) }()
    return c
}

タイプArgの明示的な制約をどのように表現しますか？ それらはFの特定のインスタンス化に依存します。 この種の依存関係は、最近の制約に関する提案の多くから欠落しているようです。

いいえ。Vは型であり、変数tは使用されていないため、uv（V）は構文エラーです。

ただし、この関数を定義することはできます。これは、意図したものである可能性があります。

はい、それが意図でした、私の謝罪。

U.vの戻り型は数値であり、 Tに割り当てることができるため、型Tは数値である必要があります。

これを本当に制約と見なす必要がありますか？ 他の制約から推測できますが、これを別個の制約と呼ぶことは多かれ少なかれ有用ですか？ 暗黙の制約は、明示的な制約が行わない方法でこの質問をします。

はい、それは本当です。しかし、制約を省略することは、それらの制約が暗黙的であるかどうかにかかわらず、重大な欠陥になります。 IMO、制約のより重要な役割は、あいまいさを解決することです。 たとえば、上記の制約では、コンパイラはuvを単一引数または可変個引数メソッドとしてインスタンス化する準備をする必要があります。

私はその言葉のように「私たちが許す制約」を意味しました。 明示的な制約を使用すると、制約が「コンパイルするものは何でも」であると言うよりも、ユーザーが記述できる制約の種類を決定する方がはるかに簡単です。 たとえば、上記のFooの例には、実際にはT 、 U 、またはVとは別の暗黙の追加タイプが含まれています。これは、の戻りタイプを考慮する必要があるためです。 u.v 。 このタイプは、 fの宣言では明示的に参照されません。 必要なプロパティは完全に暗黙的です。 同様に、上位（ forall ）のタイプを許可しますか？ 頭のてっぺんから例を思いつくことはできませんが、上位の型境界を暗黙的に記述できないことを自分自身に納得させることもできません。

もう1つの例は、関数がオーバーロードされた構文を利用できるようにする必要があるかどうかです。 暗黙的に制約された関数がジェネリック型Tのtに対してfor i := range tを実行する場合、 Tが任意の配列、スライス、チャネル、またはマップ。 ただし、特にTがチャネルタイプの場合、セマンティクスはまったく異なります。 たとえば、 t == nil （ Tが配列である限り発生する可能性があります）の場合、nilスライスまたはマップに要素がないため、反復は何も行わないか、永久にブロックされますそれがnilチャネルで受け取るものだからです。 これは起こるのを待っている大きなフットガンです。 同様にm[i] = ...を実行しています; mをマップにする場合は、範囲外の割り当てでコードがパニックになる可能性があるため、実際にはスライスになるのを防ぐ必要があります。

実際、これは暗黙の制約に対する別の議論に役立つと思います。APIの作成者は、制約を追加するためだけに人工的なステートメントを作成する場合があります。 たとえば、 for _, _ := range t { break }は、マップ、スライス、および配列を許可しながら、チャネルを防止します。 x = append(x)は、 xにスライスタイプを強制します。 var _ = make(T, 0)は、スライス、マップ、およびチャネルを許可しますが、配列は許可しません。 制約を暗黙的に追加して、正しいコードを記述していない型で誰かが関数を呼び出せないようにする方法のレシピ本があります。 キータイプも知らない限り、マップタイプのみをコンパイルするコードを作成する方法を考えることすらできません。 そして、これはまったく仮説ではないと思います。 マップとスライスは、ほとんどのアプリケーションでまったく異なる動作をします

この例では競合する制約が見られないため、何を求めているのかよくわかりません。 「違法な制約」とはどういう意味ですか？

言語が上位の制約を許可しないことを決定した場合など、言語で許可されていない制約を意味します。

関連するすべての制約を型システムで表現できるわけではありません（＃22876（コメント）も参照）。 一部の制約は、実行時のパニックによって強制されます。 一部はレース検出器によって強制されます。 最も危険な制約は単に文書化されており、まったく検出されていません。

これらはすべて、ある程度「内部の詳細を漏らしている」。 （https://xkcd.com/1172/も参照してください。）

＃22876がどのようにこれに入るのかはよくわかりません。 これは、型システムを使用して別の種類の制約を表現しようとしています。 任意の複雑さの型システムであっても、値やプログラムにいくつかの制約を表現できないことは常に真実です。 ただし、ここでは型の制約についてのみ説明しています。 コンパイラは、「このジェネリックをタイプTでインスタンス化できますか？」という質問に答えられる必要があります。 つまり、暗黙的であろうと明示的であろうと、制約を理解する必要があります。 （C ++やRustなどの一部の言語は、任意の計算に依存する可能性があり、したがって停止性問題に発展するため、一般にこの質問を決定できないことに注意してください。ただし、満たす必要のある制約を表現します。）

私が言いたいのは、「次の例ではどのようなエラーメッセージが表示されるのか」ということです。

func [U] DirectlyConstrained(U t) {
    t.DoSomething();
}
func [T] IndirectlyConstrained(T t) {
    DirectlyConstrainted(t);
}
func Illegal() {
    IndirectlyConstrained(4);
}

Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething()と言うことができます。 このエラーメッセージは、 IndirectlyConstrainedのユーザーに役立ちます。これは、それらが欠落しているという制約を明確に示しているためです。 しかし、 IndirectlyConstrainedにその制約がある理由をデバッグしようとしている人には情報が提供されません。これは、大きな関数の場合、使いやすさの大きな問題です。 Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line Nを追加することもできますが、現在、 IndirectlyConstrainedの実装の詳細がリークされています。 さらに、 IndirectlyConstrainedに制約がある理由については説明していません。それで、別のNote: this constraint exists on U because DirectlyConstrained calls t.DoSomething() on line Mを追加しますか？ 暗黙の制約が、呼び出しスタックの4レベル下の呼び出し先から発生した場合はどうなりますか？

さらに、パラメータとして明示的にリストされていないタイプのこのエラーメッセージをどのようにフォーマットしますか？ たとえば、上記の例の場合、 IndirectlyConstrainedはDirectlyConstrained(t.U()) $を呼び出します。 タイプをどのように参照するのですか？ この場合、 the type of t.U()と言うことができますが、値は必ずしも単一の式の結果であるとは限りません。 複数のステートメントで構成されている可能性があります。 次に、エラーメッセージを入力するために、コードに表示されない式を正しい型で合成するか、それを参照する他の方法を見つける必要があります。制約に違反した貧しい発信者。

タイプArgの明示的な制約をどのように表現しますか？ それらはFの特定のインスタンス化に依存します。その種の依存関係は、制約に関する最近の提案の多くから欠落しているようです。

Fをドロップし、 f func (Arg) Resultします。 はい、可変個引数関数を無視しますが、Goの残りの部分も無視します。 varargs funcsを互換性のある署名に割り当て可能にする提案は、個別に行うことができます。

本当に高次の型境界が必要な場合は、ジェネリックスv1にそれらを含めることが意味がある場合とない場合があります。 明示的な制約により、高次の型をサポートするかどうか、およびその方法を明示的に決定する必要があります。 これまでのところ考慮されていないのは、Goが現在組み込み型のプロパティを参照する方法がないという事実の兆候だと思います。 これは、ジェネリックシステムがすべての数値型またはすべての整数型に対してジェネリック関数をどのように許可するかについての一般的な未解決の質問であり、ほとんどの提案はこれにあまり焦点を当てていません。

次のプロジェクトで私のジェネリックスの実装を評価してください
http://go-li.github.io/

Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething()と言うことができます。 このエラーメッセージ[…]は、 IndirectlyConstrainedにその制約がある理由をデバッグしようとしている人には情報を提供しません。これは、大きな関数の場合、ユーザビリティの大きな問題です。

ここであなたがしている大きな仮定を指摘したいと思います。 go buildからのエラーメッセージは、プログラマーが問題を診断するために利用できる唯一のツールであるということです。

例えを使用すると、実行時にerrorが発生した場合、デバッグのためのいくつかのオプションがあります。 エラー自体には単純なメッセージのみが含まれており、エラーを説明するのに十分な場合とそうでない場合があります。 ただし、入手できる情報はこれだけではありません。たとえば、プログラムが発行したログステートメントもあり、それが本当に厄介なバグである場合は、インタラクティブデバッガーにロードできます。

つまり、ランタイムデバッグはインタラクティブなプロセスです。 では、なぜコンパイル時エラーの非対話型デバッグを想定する必要があるのでしょうか⸮1つの代替手段として、型の制約についてguruツールに教えることができます。 その場合、コンパイラからの出力は次のようになります。

somefile.go:123: Argument `4` to DirectlyConstrained has type `int`,
    but DirectlyConstrained requires a type `T` with method `DoSomething()`.
    (For more detail, run `guru contraints path/to/somefile.go:#1033`.)

これにより、汎用パッケージのユーザーは、即時呼び出しサイトをデバッグするために必要な情報を得ることができますが、_また_は、パッケージメンテナー（そして重要なことに、編集環境！）がさらに調査するためのパンくずリストを提供します。

Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line Nを追加することもできますが、現在、 IndirectlyConstrainedの実装の詳細がリークされています。

はい、それはとにかく情報が漏れることについて私が意味することです。 すでにguru describeを使用して、実装の内部を覗くことができます。 デバッガーを使用して実行中のプログラムの内部を覗き見し、スタックを検索するだけでなく、任意の低レベル関数にステップダウンすることもできます。

関係のない可能性のある情報を_デフォルトで_非表示にする必要があることに完全に同意しますが、それは絶対に非表示にする必要があるという意味ではありません。

暗黙的に制約された関数がジェネリック型Tの一部のtに対してi := range tを実行する場合、 Tが任意の配列、スライス、チャネルである場合、構文は機能します。 、またはマップ。 ただし、特にTがチャネルタイプの場合、セマンティクスはまったく異なります。

これは型制約のより説得力のある議論だと思いますが、明示的な制約が一部の人々が提案しているものと同じくらい冗長である必要はありません。 呼び出しサイトの曖昧さを解消するには、タイプパラメータをreflect.Kindに近いもので制約するだけで十分なようです。 コードからすでに明らかな操作を説明する必要はありません。 代わりに、「 Tはスライスタイプです」などと言うだけで済みます。 これにより、はるかに単純な一連の制約が発生します。

• インデックス操作の対象となるタイプは、線形または結合としてラベル付けする必要があります。
• range演算の対象となる型は、nil-emptyまたはnil-blockingとしてラベル付けする必要があります。
• リテラルを持つタイプは、フィールドまたはインデックスを持つものとしてラベル付けする必要があります。
• （おそらく）数値演算のある型は、固定小数点または浮動小数点としてラベル付けする必要があります。

それは、おそらく次のような、はるかに狭い制約言語につながります。

TypeConstraint = "sliceable" | "map" | "chan" | "struct" | "integer" | "float" | "type"

次のような例で：

func[T:integer, U, V] Foo(u U, v V) {
    var _ T = u.v(v) + 1;
}

func [S:sliceable, T] append(s S, x ...T) S {
    dst := s
    if cap(s) - len(s) < len(x) {
        dst = make(S, len(s), nextSizeClass(cap(s)))
        copy(dst, s)
    }
    copy(dst[len(s):cap(s)], x)
    return dst[:len(s)+len(x)]
}

タイプエイリアスを導入することで、カスタムジェネリックに向けて大きな一歩を踏み出したと感じています。
タイプエイリアスはスーパータイプ（タイプのタイプ）を可能にします。
使用時に値のように型を扱うことができます。

説明を簡単にするために、新しいコード要素genreを追加できます。
ジャンルとタイプの関係は、タイプと値の関係に似ています。
言い換えれば、ジャンルはタイプのタイプを意味します。

構造体、インターフェース、関数の種類を除く各種類のタイプは、事前に宣言されたジャンルに対応しています。

• ブール
• 弦
• Int8、Uint8、Int16、Uint16、Int32、Uint32、Int64、Uint64、Int、Uint、Uintptr
• Float32、Float64
• Complex64、Complex128
• 配列、スライス、マップ、チャネル、ポインター、UnsafePointer

Comaprable、Numeric、Interger、Float、Complex、Containerなど、他にもいくつかの事前に宣言されたジャンルがあります。 Typeまたは*は、すべてのタイプのジャンルを示します。

すべての組み込みジャンルの名前はすべて大文字で始まります。

各構造体、インターフェース、および関数のタイプは、ジャンルに対応しています。

カスタムジャンルを宣言することもできます。

genre Addable = Numeric | String
genre Orderable = Interger | Float | String
genre Validator = func(int) bool // each parameter and result type must be a specified type.
genre HaveFieldsAndMethods = {
    width  int // we must use a specific type to define the fields.
    height int // we can't use a genre to define the fields.
    Load(v []byte) error // each parameter and result type must be a specified type.
    DoSomthing()
}
genre GenreFromStruct = aStructType // declare a genre from a struct type
genre GenreFromInterface = anInterfaceType // declare a genre from an interface type
genre GenreFromStructInterface = aStructType + anInterfaceType
genre ComparableStruct = HaveFieldsAndMethods & Comprable
genre UncomparableStruct = HaveFieldsAndMethods &^ Comprable

以下の説明を一貫させるには、ジャンル修飾子が必要です。
ジャンル修飾子はConstで示されます。 例えば：

• Const Integerはジャンル（ Integerとは異なります）であり、そのインスタンスは定数値である必要があり、タイプは整数である必要があります。 ただし、定数値は特殊なタイプと見なすことができます。
• Const func(int) boolはジャンル（ func(int) boolとは異なります）であり、そのインスタンスは削除された関数値である必要があります。 ただし、関数宣言は特殊な型と見なすことができます。

（モディファイアソリューションには注意が必要です。他にも優れた設計ソリューションがあるかもしれません。）

では、続けましょう。
別の概念が必要です。 それの良い名前を見つけるのは簡単ではありません、
それをcrateと呼びましょう。
一般的に、木枠とジャンルの関係は、機能とタイプの関係に似ています。
クレートは、型をパラメーターおよび戻り型として受け取ることができます。

クレート宣言（次のコードがlibパッケージで宣言されていると仮定します）：

crate Example [T Float, S {width, height T}, N Const Integer] [*, *, *] {
    type MyArray [N]T

    func Add(a, b T) T {
        return a+b
    }

    type M struct {
        x T
        y S
    }

    func (m *M) Area() T {
        m.DoSomthing()
        return m.y.width * m.y.height
    }

    func (m *M) Perimeter() T {
        return 2 * Add(m.y.width, m.y.height)
    }

    export M, Add, MyArray
}

上記のクレートを使用します。

import "lib"

// We can use AddFunc as a normal delcared function.
// Its genre is "Const func (a, b T) T"
type Rect, AddFunc, Array = lib.Example[float32, struct{x, y float32}, 100]

func demo() {
    var r Rect
    a, p = r.Area(), r.Perimeter()
    _ = AddFunc(a, p)
}

私のアイデアは、上記の他のアイデアの多くを吸収します。
彼らは今ではあまり成熟していません。
面白いと思うので、ここに投稿します。
これ以上改善したくありません。
アイデアの穴を修正することで、非常に多くの脳細胞が殺されました。
これらのアイデアが他のゴファーにインスピレーションをもたらすことを願っています。

あなたが「ジャンル」と呼ぶものは実際には「種類」と呼ばれ、
関数型プログラミングコミュニティ。 あなたが木枠と呼ぶものは制限されています
MLファンクターの一種。

2018年4月4日水曜日、午後12時41分[email protected]は次のように書いています。

導入することで、カスタムジェネリックに向けて大きな一歩を踏み出したと感じています
タイプエイリアス。
タイプエイリアスはスーパータイプ（タイプのタイプ）を可能にします。
使用時に値のように型を扱うことができます。

説明を簡単にするために、新しいコード要素genreを追加できます。
ジャンルとタイプの関係はタイプの関係のようなものです
と値。
言い換えれば、ジャンルはタイプのタイプを意味します。

構造体、インターフェース、関数の種類を除く、各種類の型、
事前に宣言されたジャンルに対応します。

• ブール
• 弦
• Int8、Uint8、Int16、Uint16、Int32、Uint32、Int64、Uint64、Int、Uint、
  Uintptr
  ＆Float32、Float64
• Complex64、Complex128
• 配列、スライス、マップ、チャネル、ポインター、UnsafePointer

Comaprable、Numeric、など、他にもいくつかの事前に宣言されたジャンルがあります。
Interger、Float、Complex、Containerなど。Typeまたは*はを使用できます。
すべてのタイプのジャンル。

すべての組み込みジャンルの名前はすべて大文字で始まります。

各構造体、インターフェース、および関数のタイプは、ジャンルに対応しています。

カスタムジャンルを宣言することもできます。

ジャンル追加可能=数値| 弦
ジャンル注文可能= Interger | フロート| 弦
genre Validator = func（int）bool //各パラメーターと結果の型は指定された型である必要があります。
ジャンルHaveFieldsAndMethods = {
width int //フィールドを定義するには特定のタイプを使用する必要があります。
height int //ジャンルを使用してフィールドを定義することはできません。
Load（v [] byte）error //各パラメーターと結果タイプは指定されたタイプでなければなりません。
DoSomthing（）
}
genreGenreFromStruct = aStructType //構造体タイプからジャンルを宣言します
genreGenreFromInterface = anInterfaceType //インターフェースタイプからジャンルを宣言します
ジャンルGenreFromStructInterface = aStructType | anInterfaceType

以下の説明を一貫させるには、ジャンル修飾子が必要です。
ジャンル修飾子はConstで表されます。 例えば：

• Const Integerはジャンルであり、そのインスタンスは定数値である必要があります
  どの型は整数でなければなりません。
  ただし、定数値は特殊なタイプと見なすことができます。
• Const func（int）boolはジャンルであり、そのインスタンスは削除されている必要があります
  関数値。
  ただし、関数宣言は特殊な型と見なすことができます。

（モディファイアソリューションはトリッキーですが、他のより良いデザインがあるかもしれません
ソリューション。）

では、続けましょう。
別の概念が必要です。 それの良い名前を見つけるのは簡単ではありません、
それをクレートと呼びましょう。
一般的に、木枠とジャンルの関係は、関係のようなものです
関数とタイプの間。
クレートは、型をパラメーターおよび戻り型として受け取ることができます。

クレート宣言（次のコードがlibで宣言されていると仮定します）
パッケージ）：

クレートの例[TFloat、S {width、height T}、N Const Integer] [*、*、*] {
MyArray [N] Tと入力します

func Add（a、b T）T {
a + bを返す
}

//クレートスコープのジャンル。 木枠でのみ使用できます。

// MはジャンルGの一種です
タイプMstruct {
x T
y S
}

func（m * M）Area（）T {
m.DoSomthing（）
mywidth * myheightを返します
}

func（m * M）Perimeter（）T {
return 2 * Add（mywidth、myheight）
}

M、Add、MyArrayをエクスポートします
}

上記のクレートを使用します。

「lib」をインポート

// AddFuncを通常の削除された関数として使用できます。
タイプRect、AddFunc、Array = lib.Example（float32、struct {x、y float32}）

func demo（）{
var r Rect
a、p = r.Area（）、r.Perimeter（）
_ = AddFunc（a、p）
}

私のアイデアは、上記の他のアイデアの多くを吸収します。
彼らは今ではあまり成熟していません。
面白いと思うので、ここに投稿します。
これ以上改善したくありません。
アイデアの穴を修正することで、非常に多くの脳細胞が殺されました。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment-378665695 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AGGWB78BrjN0BxRfroH-jRNy4mCXgSwCks5tlPfMgaJpZM4IG-xv
。

種類とジャンルには違いがあると思います。

ちなみに、クレートが1つのタイプしか返さない場合は、その呼び出しをタイプとして直接使用できます。

package lib

// export a type
crate List [T *] * {
    type List struct {
        ...
    }

    export List
}

これを使って：

import "lib"

var l lib.List[int]

現在のシステムの「タイプの控除」と同じように、いくつかの「ジャンルの控除」ルールがあります。

@ dotaheor 、 @ DemiMarieは正しいです。 あなたの「ジャンル」の概念は、型理論の「種類」とまったく同じように聞こえます。 （あなたの提案はたまたまサブキンディングルールを必要としますが、それは珍しいことではありません。）

プロポーザルのgenreキーワードは、新しい種類を既存の種類のスーパー種類として定義します。 crateキーワードは、 Typeのサブカインドではない種類の「クレート署名」を持つオブジェクトを定義します。

正式なシステムとして、あなたの提案は次のように思われます。

クレート:: = χ | ⋯
タイプ:: = τ | χ | int | bool | ⋯| func(τ) | func(τ) τ | []τ | χ[τ₁, …]

CrateSig :: = [κ₁, …] ⇒ [κₙ, …]
種類:: = κ | exactly τ | kindOf κ | Map | Chan | ⋯| Const κ | Type | CrateSig

いくつかの型理論表記を乱用するには：

• 「⊢」を「含意」と読みます。
• 「 k1 ⊑ k2 」を「 k1はk2のサブカインドです」と読みます。
• 「：」を「親切」と読みます。

その場合、ルールは次のようになります。

⊢ τ ： exactly τ
⊢ exactly τ ⊑ kindOf exactly τ
⊢ kindOf exactly τ ⊑ Type

τ ： κ₁ ∧ κ₁ ⊑ κ₂ ⊢ τ ： κ₂

τ₁ ： Type ∧ τ₂ ： Type ⊢ kindOf exactly map[τ₁]τ₂ ⊑ Map
⊢ Map ⊑ Type

κ₁ ⊑ κ₂ ⊢ Const κ₁ ⊑ Const κ₂

[…]
（以下同様、すべての組み込みの種類について）

型定義は種類を与え、基礎となる種類は組み込み型の種類に崩壊します。

type τ₁ τ₂ ∧ τ₂ ： κ ⊢ τ₁ ： kindOf κ

⊢ kindOf kindOf κ ⊑ kindOf κ
⊢ kindOf Map ⊑ Map
[…]

genreは、新しいサブタイプの関係を定義します。
genre κ = κ₁ | κ₂ ⊢ κ₁ ⊑ κ
genre κ = κ₁ | κ₂ ⊢ κ₂ ⊑ κ

（ Numericなどは|で定義できます。）

genre κ = κ₁ & κ₂ ∧（ κ₃ ⊑ κ₁ ）∧（ κ₃ ⊑ κ₂ ）⊢ κ₃ ⊑ κ

クレート拡張ルールは似ています：
type τₙ, … = χ[τ₁, …] ∧（ χ ： [κ₁, …] ⇒ [κₙ, …] ）∧（ τ₁ ： κ₁ ）∧⋯⊢ τₙ ： κₙ

もちろん、これはすべて種類について話しているだけです。 型システムに変換したい場合は、型ルールも必要です。 🙂

つまり、あなたが説明しているのは、かなりよく理解されている形式のパラメトリシティです。 それはよく理解されているという点で素晴らしいですが、Goがもたらす固有の問題を解決するのに役立たないという点で残念です。

Goがもたらす本当に面白くて厄介な問題は、主に動的型検査に関するものです。 型パラメーターは型アサーションおよびリフレクションとどのように相互作用する必要がありますか？

（たとえば、パラメトリック型のメソッドを使用してインターフェイスを定義できるようにする必要がありますか？その場合、実行時に新しいパラメーターを使用してそのインターフェイスの値をタイプアサートするとどうなりますか？）

関連するメモとして、組み込み型やユーザー定義型に対してコードを汎用化する方法についての議論がありましたか？ bigintやプリミティブ整数を処理できるコードを作成するなど？

関連するメモとして、組み込み型やユーザー定義型に対してコードを汎用化する方法についての議論がありましたか？ bigintやプリミティブ整数を処理できるコードを作成するなど？

GenusやFamiliaなどの型クラスベースのメカニズムは、これを効率的に行うことができます。 詳細については、PLDI2015のペーパーを参照してください。

@DemiMarie
「ジャンル」==「特性セット」だと思います。

[編集]
たぶんtraitsはより良いキーロッドです。
それぞれの種類を見ることができるのも特性セットです。

ほとんどの特性は、単一のタイプに対してのみ定義されています。
しかし、より複雑な特性は、2つのタイプ間の関係を定義する場合があります。

[編集2]
2つの特性セットAとBがあると仮定すると、次の操作を実行できます。

A + B: union set
A - B: difference set
A & B: intersection set

引数タイプの特性セットは、対応するパラメータージャンルのスーパーセット（特性セット）である必要があります。
結果タイプの特性セットは、対応する結果ジャンルのサブセット（特性セット）である必要があります。

（私見では）

それでも、ジェネリックスをGoに追加するには、TypeAliasesを再バインドするのが良い方法だと思います。 言語を大幅に変更する必要はありません。 このように一般化されたパッケージは、Go1.xでも使用できます。 また、タイプエイリアスのデフォルトのタイプを、すでにそれらの制約を満たしているものに設定することで追加できるため、制約を追加する必要はありません。 また、型エイリアスの再バインドの最も重要な側面は、組み込みの複合型（スライス、マップ、およびチャネル）を変更して一般化する必要がないことです。

@ dc0d

タイプエイリアスはジェネリックをどのように置き換える必要がありますか？

@sighoyaタイプエイリアスの再バインドは、ジェネリック（タイプエイリアスだけでなく）を置き換えることができます。 パッケージが次のようなパッケージレベルのタイプエイリアスを導入すると仮定しましょう。

package likedlist

type T = interface{}

type LinkedList struct {
    // ...
}

タイプエイリアスの再バインド（およびコンパイラ機能）が提供されている場合は、空のインターフェイスの代わりに、このパッケージを使用して、さまざまな具象タイプのリンクリストを作成できます。

package main

import (
    "likedlist"
)

type intLL = likedlist.LinkedList(likedlist.T = int)
type stringLL = likedlist.LinkedList(likedlist.T = string)

func main() {}

エイリアスをそのまま使用する場合は、次の方法の方がわかりやすくなります。

// pkg.go
package pkg

type ListNode struct {
    prev, next *ListNode
    element    ?Element
}

func Add(x, y ?T) ?T {
    return x+y
}



// main.go
package main

import "pkg"

type intList = pkg.ListNode[Element=int]
func stringAdd = pkg.Add[T=string]

func main() {
}

@ dc0dとそれはどの程度正確に実装されますか？ コードは素晴らしいですが、実際に内部でどのように機能するかについては何も教えてくれません。 そして、ジェネリック医薬品の提案の歴史を見ると、Goにとっては、見た目や感触だけでなく、非常に重要です。

@dotaheorこれはGo1.xと互換性がありません。

@crekerこの手法を使用してコードを生成し、Type Alias Rebindingの概念として生まれたツール（ goreuseという名前）を実装しました。

ここで見つけることができます。 ツールを説明する15分のビデオがあります。

@ dc0dなので、特殊な実装を生成するC ++テンプレートのように機能します。 Goチーム（そして率直に言って、私とここにいる他の多くの人々）がC ++テンプレートに似たものに反対しているように思われるので受け入れられるとは思いません。 バイナリが増え、コンパイルが遅くなり、意味のあるエラーが発生しない可能性があります。 そして、それに加えて、Goがサポートしているバイナリのみのパッケージとは互換性がありません。 これが、C ++がヘッダーファイルにテンプレートを書き込むことを選択した理由です。

@creker

したがって、C ++テンプレートのように機能し、使用されるすべてのタイプに特化した実装を生成します。

わかりません（C ++を作成してから約16年になります）。 しかし、あなたの説明から、それは事実のようです。 それでも、それらが同じであるかどうか、またはどのように同じであるかはわかりません。

Goチーム（そして率直に言って、私とここにいる他の多くの人々）がC ++テンプレートに似たものに反対しているように思われるので受け入れられるとは思いません。

確かに、ここの誰もが彼らの優先順位に基づいて彼らの好みの正当な理由を持っています。 私のリストの最初は、Go1.xとの互換性です。

バイナリを増やし、

かもしれない。

コンパイルが遅くなり、

私はそれを非常に疑っています（ goreuseで経験できるので）。

そして、それに加えて、Goがサポートしているバイナリのみのパッケージとは互換性がありません。

私はわかりません。 ジェネリックを実装する他の方法はこれをサポートしていますか？

意味のあるエラーを生成できない可能性があります。

これは少し面倒かもしれません。 それでも、コンパイル時に発生し、いくつかのツールを使用して、大幅に補償することができます。 さらに、パッケージの型パラメーターとして機能する型エイリアスがインターフェースである場合は、具体的に提供された型から割り当て可能であることを簡単に確認できます。 intやstringなどのプリミティブ型や構造体の問題は残っていますが。

@ dc0d

私はそれについて少し考えます。
インターフェイスで内部的に確立されていることに加えて、例の「T」

type T=interface{}

は可変型変数として扱われますが、特定の型のエイリアス、つまり型へのconst参照である必要があります。
必要なのはTタイプですが、これはジェネリックの導入を意味します。

@sighoyaあなたの言ったことを理解できるかどうかわかりません。

インターフェイス上で内部的に確立されます

違います。 私の元のコメントで説明したように、制約を満たす特定のタイプを使用することが可能です。 たとえば、typeパラメータtypealiasは次のように宣言できます。

type T = int

また、型の値として使用できるのは、 +演算子（または-または* ;その演算子がパッケージの本体で使用されているかどうかによって異なります）を持つ型のみです。それはその型パラメータにあります。

したがって、型パラメーターのプレースホルダーとして使用できるのはインターフェースだけではありません。

しかし、これはジェネリック医薬品の導入を意味します。

これは、Go言語自体でジェネリックスを導入/実装するための方法です。

@ dc0d

ポリモーフィズムを提供するには、後でTを任​​意のタイプに設定できるため、interface {}を使用します。

'type T = Int'を設定してもあまり効果はありません。

'type T'が最初に未宣言/未定義であり、後で設定できると言えば、ジェネリックスのようなものがあります。

問題は、「T」がモジュール/パッケージ全体を保持し、関数や構造体に対してローカルではないことです（大丈夫、外部からアクセスできる構造体のネストされた型宣言かもしれません）。

代わりに書いてみませんか？：

fun<type T>(t T)

また

fun[type T](t T)

さらに、最初に型パラメーターの特殊化なしでジェネリック関数または構造体を呼び出すときに正しい型を推測するために、いくつかの型推論機構が必要です。

@ dc0dは書いた

また、その型パラメーターに含まれる型値として使用できるのは、+演算子（または-または*;その演算子がパッケージの本体で使用されているかどうかによって異なります）を持つ型のみです。

これについて詳しく教えていただけますか？

@sighoya

ポリモーフィズムを提供するには、後でTを任​​意のタイプに設定できるため、interface {}を使用します。

型エイリアスを再バインドするときに、互換性のある型を使用しても、ポリモーフィズムは実現されません。 唯一の実際の制約は、汎用パッケージの本体です。 それらは機械的に互換性がなければなりません。

これについて詳しく教えていただけますか？

たとえば、パッケージレベルタイプのパラメータタイプエイリアスが次のように定義されている場合：

package genericadd

type T = int

func Add(a, b T) T { return a + b }

次に、実質的にすべての数値型を次のようにTに割り当てることができます。

package main

import (
    "genericadd"
)

var add = genericadd.Add(
    T = float64
)

func main() {
    var (
        a, b float64
    )

    println(add(a, b))
}

@ dc0d

それでも、それらが同じであるかどうか、またはどのように同じであるかはわかりません。

それらは、私が見ているものとほとんど同じように機能するという意味で同じです。 クラステンプレートとそのパラメータリストの特定の組み合わせの使用法を初めて確認する場合、すべてのクラステンプレートのインスタンス化コンパイラは一意の実装を生成します。 同じクラステンプレートの実装が複数あるため、バイナリサイズが大きくなります。 コンパイラがこれらの実装を生成し、あらゆる種類のチェックを行う必要があるため、コンパイルが遅くなります。 C ++の場合、コンパイル時間の増加は非常に大きくなる可能性があります。 あなたのおもちゃの例は速いですが、C ++のものもそうです。

私はわかりません。 ジェネリックを実装する他の方法はこれをサポートしていますか？

他の言語はそれで問題ありません。 特に、私にとって最も馴染みのあるC＃です。 ただし、Goチームが完全に除外するランタイムコード生成を使用します。 Javaも機能しますが、控えめに言っても、その実装は最善ではありません。 ianlancetaylorの提案の中には、私が理解しているものからバイナリのみのパッケージを処理できるものもあります。

私が理解していない唯一のことは、バイナリのみのパッケージをサポートする必要があるかどうかです。 提案の中でそれらが明確に言及されているのを見ていません。 私はそれらについてはあまり気にしませんが、それでも、それは言語機能です。

私の理解をテストするために...コピー/貼り付けアルゴリズムのこのリポジトリを検討してください[ここ]。 「int」を使用しない限り、コードを直接使用することはできません。 動作させるには、コピーして貼り付け、変更する必要があります。 そして、変更とは、「int」の各インスタンスを本当に必要なタイプに変更する必要があることを意味します。

タイプエイリアスアプローチでは、たとえばTに一度変更を加え、「typeTint」という行を挿入します。 次に、コンパイラはTを他の何か（float64など）に再バインドする必要があります。

したがって：
a）実際にこの手法を使用しない限り、コンパイラの速度低下はないと主張します。 だからそれはあなたの選択です。
b）同じコードの複数のバージョンを使用できる新しいvgoのものを考えると...つまり、使用されているソースを見えない場所に押し込める方法が必要であるため、コンパイラは2つかどうかを確実に追跡できます。同じ再バインドの使用が使用され、重複を回避します。 したがって、コードの膨張は現在のコピー/貼り付けの手法と同じだと思います。

型エイリアスと今後のvgoの間で、ジェネリックスへのこのアプローチの基盤はほぼ完成しているように思われます...

提案[ここ]にリストされているいくつかの「未知数」があります。 ですから、もう少し具体化するといいでしょう。

@mandolyte特殊な型をいくつかの一般的なコンテナーでラップすることにより、別のレベルの間接参照を追加できます。 そうすれば、実装は同じままになります。 その後、コンパイラはすべての魔法を実行します。 イアンのタイプパラメータの提案はそのように機能すると思います。

ユーザーは型消去と単形化のどちらかを選択する必要があると思います。
後者は、Rustがゼロコストの抽象化を提供する理由です。 行くべきです。

2018年4月9日月曜日、午前8時32分Antonenko [email protected]
書きました：

@mandolytehttps ：//github.com/mandolyte別のレベルを追加できます
特殊な型をいくつかの一般的なコンテナでラップすることによる間接参照。 それか
実装を同じに保つ方法。 その後、コンパイラはすべてを実行します
魔法。 イアンのタイプパラメータの提案はそのように機能すると思います。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment-379735199 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AGGWB1v9h5kWmuHCBuoewTTSX751OHgrks5tm1TsgaJpZM4IG-xv
。

モジュール性とパフォーマンスの間のトレードオフについてのこの議論には、理解できる混乱があるように思われます。 使用されるすべての型でジェネリックコードを再型チェックしてインスタンス化するC ++手法は、モジュール性、バイナリディストリビューション、およびコードの膨張のためにパフォーマンスに悪影響を及ぼします。 このアプローチの良いところは、生成されたコードを使用されている型に自動的に特化することです。これは、使用されている型がintのようなプリミティブ型である場合に特に役立ちます。 Javaはジェネリックコードを均一に変換しますが、特にコードがタイプT[]を使用する場合、パフォーマンスに代償を払います。

幸い、C ++の非モジュール性や完全な実行時コード生成なしで、これに対処する方法はいくつかあります。

1. プリミティブ型の特殊なインスタンス化を生成します。 これは、自動的に、またはプログラマーの指示によって行うことができます。 正しいインスタンス化にアクセスするには、ある程度のディスパッチが必要ですが、同種の変換ですでに必要なディスパッチに折りたたむことができます。 これはC＃と同様に機能しますが、完全なランタイムコード生成は必要ありません。 コードのロード時にディスパッチテーブルを設定するには、ランタイムで少し追加のサポートが必要になる場合があります。
2. Tがプリミティブ型としてインスタンス化されるときに、Tの配列が実際にプリミティブ型の配列として表される単一のジェネリック実装を使用します。 PolyJ、Genus、およびFamiliaで使用したこのアプローチは、完全に特殊化された実装ほど高速ではありませんが、Javaアプローチに比べてパフォーマンスを大幅に向上させます。

@ dc0d

型エイリアスを再バインドするときに、互換性のある型を使用しても、ポリモーフィズムは実現されません。 唯一の実際の制約は、汎用パッケージの本体です。 それらは機械的に互換性がなければなりません。

型エイリアスは、定数参照である必要があるため、間違った方法です。
'T Type'を直接書く方が良いです。そうすれば、実際にジェネリックを使用していることがわかります。

パッケージ/モジュール全体にグローバル型変数「T」を使用する理由は、<>または[]のローカル型変数がよりモジュール化されているためです。

@creker

特に、私にとって最も馴染みのあるC＃です。 ただし、Goチームが完全に除外するランタイムコード生成を使用します。

参照型用ですが、値型用ではありません。

@DemiMarie

ユーザーは型消去と単形化のどちらかを選択する必要があると思います。
後者は、Rustがゼロコストの抽象化を提供する理由です。 行くべきです。

「型消去」はあいまいです。Javaが提供する型パラメータ消去を意味していると思いますが、これもまったく真実ではありません。
Javaには単形化がありますが、ほとんどがObjectである一般的な制約の上限まで常に単形化（半）します。
他のタイプのメソッドとフィールドを提供するために、上限は内部的に適切なタイプにキャストされますが、これは非常に醜いです。
Valhallaプロジェクトが受け入れられると、値型では状況が変わりますが、残念ながら参照型では変わりません。

次の理由により、JavaWayに移動する必要はありません。

「コンパイルされたパッケージのバイナリ互換性は、リリース間で保証されません」

一方、これはJavaでは不可能です。

モジュール性とパフォーマンスの間のトレードオフについてのこの議論には、理解できる混乱があるように思われます。 使用されるすべての型でジェネリックコードを再型チェックしてインスタンス化するC ++手法は、モジュール性、バイナリディストリビューション、およびコードの膨張のためにパフォーマンスに悪影響を及ぼします。

ここでどのようなパフォーマンスについて話しているのですか？

「コードの膨張」と「パフォーマンス」が「バイナリサイズ」と「命令キャッシュのプレッシャー」を意味する場合、問題の解決はかなり簡単です。各専門分野のデバッグ情報を過剰に保持しない限り、次のことができます。リンク時に同じボディを持つ関数を同じ関数に折りたたむ（いわゆる「ボーランドモデル」 ）。 これは、プリミティブ型と非自明なメソッドを呼び出さずに型の特殊化を簡単に処理します。

「コードの膨張」と「パフォーマンス」が「リンカー入力サイズ」と「リンク時間」を意味する場合、ビルドシステムについて特定の（合理的な）仮定を立てることができれば、問題もかなり簡単です。 すべてのコンパイルユニットで各スペシャライゼーションを発行する代わりに、必要なスペシャライゼーションのリストを発行し、リンクする前にビルドシステムに各固有のスペシャライゼーションを1回だけインスタンス化させることができます（「Cfrontモデル」）。 IIRC、これはC ++モジュールが対処しようとする問題の1つです。

したがって、私が見逃した第3の種類の「コードの膨張」と「パフォーマンス」を意味しない限り、仕様ではなく、実装の問題について話しているように見えます。_実装がデバッグを過剰に保持しない限り情報、_パフォーマンスの問題はかなり簡単に対処できます。

Goのより大きな問題は、注意しないと、型アサーションまたはリフレクションを使用して、実行時にパラメーター化された型の新しいインスタンスを生成できるようになることです。 ‐プログラム分析—修正できます。

これは確かにモジュール性の失敗ですが、コードの膨張とは何の関係もありません。代わりに、Go関数（およびメソッド）のタイプが引数に対する完全な制約のセットをキャプチャしないという事実に由来します。

@sighoya

参照型用ですが、値型用ではありません。

私が読んだことから、C＃JITは、実行時に各値型に対して、およびすべての参照型に対して1回特殊化を行います。 コンパイル時（IL時）の特殊化はありません。 これが、C＃アプローチが完全に無視される理由です-Goチームは、Goが実行できるプラットフォームを制限するため、ランタイムコード生成に依存することを望んでいません。 特に、iOSでは、実行時にコード生成を行うことは許可されていません。 それは動作し、私は実際にそれのいくつかを行いましたが、AppleはAppStoreでそれを許可していません。

どうやってやったの？

2018年4月9日月曜日、午後3時41分Antonenko [email protected]
書きました：

@sighoya https://github.com/sighoya

参照型用ですが、値型用ではありません。

私が読んだことから、C＃JITは実行時に値ごとに特殊化を行います
タイプし、すべての参照タイプに対して1回。 コンパイル時はありません
専門。 これが、C＃アプローチが完全に無視される理由です-Go team
プラットフォームを制限するため、ランタイムコード生成に依存したくない
で実行できます。 特に、iOSではコード生成を行うことは許可されていません
実行時。 それは動作し、私は実際にそれのいくつかを行いましたが、Appleは許可していません
AppStoreにあります。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment-379870005 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AGGWB-tslGeUSGXl2ZlEDLf0dCATUaYvks5tm7lvgaJpZM4IG-xv
。

@DemiMarieは、念のために私の古い調査コードを起動しました（その調査は他の理由で中止されました）。 もう一度、デバッガーは私を誤解させます。 ページを割り当て、それにいくつかの指示を書き込み、PROT_EXECでページを保護し、ジャンプします。 デバッガーの下で動作します。 デバッガーがないと、予想どおり、クラッシュログにCODESIGNメッセージが表示されてアプリがSIGKILLされます。 そのため、AppStoreがなくても機能しません。 iOSがGoにとって重要である場合、ランタイムコード生成に対するさらに強力な議論。

まず、RobPikeのプログラミングの5つのルールをもう一度考えてみると役に立ちます。

2番目（IMHO）：

遅いコンパイルとバイナリサイズについて、Goを使用して開発されている一般的なタイプのアプリケーションで使用されているジェネリック型はいくつですか（通常、ルール3の_nは小さい_）。 問題が具体的な概念（多数のタイプ）で高レベルのカーディナリティを必要としない限り、オーバーヘッドは見落とされる可能性があります。 それでも、私はそのアプローチに何か問題があると主張します。 電子商取引システムを実装する場合、製品の種類ごとに個別のタイプを定義する人は誰もいません。そのバリエーションと、おそらく可能なカスタマイズです。

冗長性は、（構文などの）単純さと親しみやすさの良い形であり、物事をより明確でわかりやすくします。 Type Alias Rebindingを使用するとコードの膨張が大きくなるとは思えませんが、おなじみのGo-ish構文とそれに伴う明らかな冗長性が好きです。 Goの目標の1つは、読みやすいことです（個人的には、書くのも比較的簡単で楽しいと思います）。

実行時に、コンパイル時に生成された具象有界型のみが使用されているため、パフォーマンスがどのように低下​​するかはわかりません。 実行時のオーバーヘッドはありません。

私が見るタイプエイリアスの再バインドに関する唯一の懸念は、バイナリ分布である可能性があります。

@ dc0dのパフォーマンスの低下は、通常、クラステンプレートの実装が異なるために、命令キャッシュがいっぱいになることを意味します。 それが実際のパフォーマンスとどの程度正確に関連しているかは未解決の質問です。ベンチマークはわかりませんが、理論的には問題です。

バイナリサイズも。 これは（以前に行ったように）人々が通常提起するもう1つの理論上の問題ですが、実際のコードがどのように苦しむかは、やはり未解決の問題です。 たとえば、すべてのポインタタイプとインターフェイスタイプの特殊化は同じである可能性があると思います。 ただし、すべての値型の特殊化は一意です。 そして、それは構造体も含みます。 ジェネリックコンテナーを使用してそれらを格納することは一般的であり、ジェネリックコンテナーの実装は小さくないため、コードが大幅に肥大化する可能性があります。

私が見るタイプエイリアスの再バインドに関する唯一の懸念は、バイナリ分布である可能性があります。

ここではまだわかりません。 ジェネリックスの提案はバイナリのみのパッケージをサポートする必要がありますか、それともバイナリのみのパッケージはジェネリックをサポートしないと言うことができますか？ それははるかに簡単でしょう、それは確かです。

前述のように、デバッグをサポートする必要がない場合は、
同一のテンプレートインスタンス化を組み合わせることができます。

2018年4月10日火曜日、午前5時46分[email protected]
書きました：

まず、RobPikeのプログラミングの5つのルールについて熟考することが役立ちます。
https://users.ece.utexas.edu/%7Eadnan/pike.htmlもう一度。

2番目（IMHO）：

遅いコンパイルとバイナリサイズについて、ジェネリック型がいくつ使用されているか
Goを使用して開発されている一般的なタイプのアプリケーション（ nは通常、ルール3）から小さいですか？ 問題が高レベルを必要としない限り
オーバーヘッドが可能である具体的な概念（多数のタイプ）のカーディナリティ
見落とされます。 それでも私は何かが間違っていると主張します
アプローチ。 eコマースシステムを実装する場合、誰も別のシステムを定義しません
製品の種類ごとにタイプし、そのバリエーションとおそらく可能性
カスタマイズ。

冗長性は、単純さと親しみやすさの良い形です（たとえば、
構文）これにより、物事がより明確でクリーンになります。 私はそれを疑うが
タイプエイリアスの再バインドを使用すると、コードの膨張が大きくなります。
おなじみのGo-ish構文とそれに伴う明らかな冗長性。 の一つ
Goの目標は読みやすいことです（私は個人的にそれを見つけていますが
書くのも比較的簡単で楽しいです）。

実行時にのみパフォーマンスに悪影響を与える可能性があるため、私はそれがどのようにパフォーマンスに悪影響を与える可能性があるのか​​理解していません
で生成されたコンクリート有界型が使用されています
コンパイル時。 実行時のオーバーヘッドはありません。

私が見るタイプエイリアスの再バインドに関する唯一の懸念は、バイナリである可能性があります
分布。

—
あなたが言及されたので、あなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment-380040032 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AGGWB6aDfoHz2wbsmu8mCGEt652G_VE9ks5tnH9xgaJpZM4IG-xv
。

インスタンス化は、「同じ引数を使用する」、または「同じ基になる型の引数を使用する」という意味で「同一」である必要はありません。 それらは、同じ生成コードを生成するために十分に接近している必要があります。 （Goの場合、これは「同じポインターマスク」も意味します。）

@creker

私が読んだことから、C＃JITは、実行時に各値型に対して、およびすべての参照型に対して1回特殊化を行います。 コンパイル時（IL時）の特殊化はありません。

バイトコードはコードが実行される直前に解釈されるため、これは少し複雑になることがあります。したがって、コード生成はプログラムの実行前にコンパイル後に行われるため、コード中に実行されているvmの意味で正しいです。が生成されます。

代わりにコンパイル時にコードを生成する場合は、c＃の汎用システムで問題ないと思います。
goはvmではないため、goではc＃の意味でのランタイムコード生成はできません。

@ dc0d

私が見るタイプエイリアスの再バインドに関する唯一の懸念は、バイナリ分布である可能性があります。

少し詳しく教えていただけますか。

@sighoya私の間違い。 私はバイナリ配布ではなくバイナリパッケージを意味しました-個人的にはそれがどれほど重要かわかりません。

@crekerいい要約！ （MO）強い理由が見つからない限り、Go言語構造のオーバーロードは避けなければなりません。 タイプエイリアスの再バインドを使用する理由の1つは、スライスやマップなどの組み込みの複合型のオーバーロードを回避するためです。

冗長性は、（構文などの）単純さと親しみやすさの良い形であり、物事をより明確でわかりやすくします。 Type Alias Rebindingを使用するとコードの膨張が大きくなるとは思えませんが、おなじみのGo-ish構文とそれに伴う明らかな冗長性が好きです。 Goの目標の1つは、読みやすいことです（個人的には、書くのも比較的簡単で楽しいと思います）。

私はこの概念に同意しません。 あなたの提案は、ユーザーにプログラマーに知られている最も難しいこと、つまり名前を付けることを強制します。 そのため、ハンガリアン記法がちりばめられたコードになってしまいます。これは見た目が悪いだけでなく、不必要に冗長で、吃音を引き起こします。 さらに、他の提案もゴイッシュな構文をもたらし、同時にこれらの問題はありません。

私たちが日常的に考案しなければならない名前には、次の3つのカテゴリがあります。

• ドメインエンティティ/ロジックの場合
• プログラムワークフローのデータ型/ロジック
• サービス/インターフェースデータ型/ロジック

プログラマーが自分のコードで何かに名前を付けることを避けて成功したことは何回ありますか？

難しいかどうかは、毎日行う必要があります。 そして、そのハードルのほとんどは、コードベースを構築する能力の欠如に起因します。命名プロセス自体の困難さではありません。 その引用は、少なくとも現在の形では、これまでのところプログラミングの世界に大きな不利益をもたらしています。 ネーミングの重要性を強調しようとするだけです。 コード内の名前を介して通信するためです。

また、コード構造化の実践に伴う名前は、はるかに強力になります。 コードレイアウト（ファイル、ディレクトリ構造、パッケージ/モジュール）とプラクティス（デザインパターン、サービスの抽象化-REST、リソース管理-並行プログラミング、ハードドライブへのアクセス、スループット/レイテンシー）の両方の観点から。

構文と冗長性に関しては、私は巧妙な簡潔さよりも冗長性を好みます（少なくともGoのコンテキストでは）-繰り返しになりますが、Goは読みやすく、必ずしも書きやすいとは限りません（奇妙なことに、それも得意です） 。

@jbahttps ：//github.com/golang/go/issues/8303およびhttps://github.com/golang/go/issues/8082を参照してください

Goでジェネリックを実装する理由と方法に関する多くの経験レポートと提案を読みました。

Goインタープリターgomacroに実際に実装しようとしてもよろしいですか？

過去に2つの言語にジェネリックスを追加したことがあるので、このトピックについてある程度の経験があります。

1. 私が素朴だったときに作成した今は放棄された言語:)それはCソースコードにトランスパイルされました
2. 私のライブラリcl-parametric-typesとのCommonLisp-ジェネリック型と関数の部分的および完全な特殊化もサポートします

@ cosmos72型安全性を維持する技術のプロトタイプを見ると、素晴らしい経験レポートになります。

作業を開始しました。 https://github.com/cosmos72/gomacro/tree/generics-v1で進捗状況を確認できます

現時点では、 https：//github.com/golang/proposal/blob/master/design/15292-generics.md#Proposalにリストされている3番目と4番目のIanの提案の（わずかに変更された）ブレンドから始めています。

@ cosmos72以下のリンクに提案の要約があります。 あなたのブレンドはそれらの1つですか？
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

私はそのドキュメントを読みました。それは、さまざまなプログラミング言語によるジェネリックスへの多くの異なるアプローチを要約しています。

現時点では、C ++、Rustなどで使用されている「型の特殊化」手法に取り組んでいます。新しい型のGoの最も一般的な構文はtype ( Foo ...; Bar ...)であり、拡張しているため、「パラメーター化されたテンプレートスコープ」が少し含まれている可能性があります。 template[T1,T2...] type ( Foo ...; Bar ...)なります。
また、「制約のある専門化」の扉を開いたままにしています。

「ポリモーフィック関数の特殊化」も実装したいと思います。つまり、プログラマーが指定しない場合、呼び出しサイトの言語によって特殊化が自動的に推測されるように調整しますが、実装はやや複雑かもしれません。 様子を見よう。

私が参照していたブレンドは、https：//github.com/golang/proposal/blob/master/design/15292/2013-10-gen.mdとhttps://github.com/golang/proposal/blob/の間です。 master / design / 15292 / 2013-12-type-params.md

更新：最初の発表を超えてこの公式のGoの問題をスパムすることを避けるために、gomacroの問題＃24でgomacro固有の議論を続ける方がおそらく良いでしょう：ジェネリックを追加する

更新2：最初のテンプレート関数がコンパイルされて正常に実行されました。 https://github.com/cosmos72/gomacro/tree/generics-v1を参照してください

念のために言っておきますが、私の意見を言い換えることができます（ジェネリックスとタイプエイリアスの再バインドについて）。

ジェネリックスは、言語機能（すべてのレベルでGoの型システムに干渉する）ではなく、コンパイラー機能（コード生成、テンプレートなど）として追加する必要があります。

@ dc0d
しかし、C ++テンプレートはコンパイラーおよび言語機能ではありませんか？

@sighoya前回C ++を専門的に書いたのは、2001年頃でした。だから、間違っているかもしれません。 しかし、命名の意味が正確であると仮定すると、「テンプレート」の部分は「はい」（または「いいえ」）です。 これは、型システムに関係する言語構造をオーバーロードしていない可能性が高いいくつかの言語構造を伴うコンパイラ機能（言語機能ではない）である可能性があります。

@ dc0dをサポートします。 あなたがそれを考えるならば、この機能は統合されたコードジェネレーターにすぎません。

はい：バイナリサイズは大きくなる可能性がありますが、現在はコードジェネレーターを使用しています。コードジェネレーターはほとんど同じですが、外部機能と同じです。 テンプレートを次のように作成する必要がある場合：

type BinaryTreeOfStrings struct {
    left, right *BinaryTreeOfStrings;
    string content;
}

// Its methods here

type BinaryTreeOfBigInts struct {
    left, right *BinaryTreeOfBigInts;
    uint64 content;
}

// AGAIN the same methods but different type

...コピーペーストしたり、外部ツールを使用したりするのではなく、この機能がコンパイラ自体の一部になることを真剣に望んでいます。

ご注意ください：

• はい、終了コードは複製されます。 まるでジェネレーターを使うかのように。 そして、バイナリはより大きくなります。
• はい、アイデアはオリジナルではありませんが、C ++から借用しています。
• はい、MyTypeの関数タイプT （直接的または間接的）の何も含まないことも繰り返されます。 これは最適化できます（たとえば、メッセージ受信オブジェクトへのポインタ以外のタイプTのメソッドは、 Tごとに生成されます;メソッドの呼び出しを保持するメソッドは、次のようになります。 Tごとに生成され、 Tごとにも再帰的に生成されます-一方、 Tへの唯一の参照がレシーバーで*Tであるメソッドは、そして、それらの安全なメソッドのみを呼び出し、同じ基準を満たす他のメソッドは、一度だけ作成できます）。 とにかく、IMOのこのポイントは大きく、ポイントには達していません。この最適化が存在しなくても、私は非常に満足しています。
• 私の意見では、型引数は明示的でなければなりません。 特に、オブジェクトが潜在的に無限のインターフェースを満たす場合。 繰り返しますが、コードジェネレーターです。

これまでの私のコメントでは、外部ツールではなく、コンパイラがサポートするコードジェネレータとしてそのまま実装することを提案しています。

GoがC ++ルートをたどるのは残念なことです。 多くの人々は、C ++アプローチを、プログラマーをジェネリックスの概念全体（デバッグの難しさ、モジュール性の欠如、コードの膨張）に逆らわせた混乱と見なしています。 すべての「コードジェネレーター」ソリューションは、実際には単なるマクロ置換です。それがコードの記述方法である場合、なぜコンパイラーのサポートが必要なのですか？

@andrewcmyersこの提案では、通常のパッケージだけを記述し、 interface{}を明示的に使用する代わりに、パッケージレベルのジェネリックパラメーターとしてtype T = interface{}として使用するType AliasRebindingを提案しました。 そしてそれがすべてです。

• 通常のパッケージのようにデバッグします。これは実際のコードであり、中間的な半減期の生き物ではありません。
• すべてのレベルでGo型システムに干渉する必要はありません。割り当て可能性だけを考えてください。
• それは明白です。 隠されたモジョはありません。 もちろん、一般的な呼び出しをシームレスにチェーンできないことに気付くかもしれませんが、これは欠点です。 私はそれをドローフォワードとして見ています！ 1つのステートメントで2つの連続した呼び出しでタイプを変更することは、Goish（IMO）ではありません。
• そして何よりも、Go 1.x（x> = 8）シリーズとの下位互換性があります。

アイデアは新しいものではありませんが、Goがそれを実装できるようにする方法は、実用的で明確です。

さらなるボーナス：Goには演算子のオーバーロードはありません。 ただし、型エイリアスのデフォルト値を（たとえば） type T = intとして定義することにより、この汎用パッケージをカスタマイズするために使用できる唯一の有効な型ではなく、 +の内部実装を持つ数値型になります。

また、いくつかのバリデータータイプとステートメントを追加するだけで、エイリアスタイプパラメーターに複数のインターフェイスを強制的に実行させることができます。

さて、これは、 ErrorおよびStringerインターフェイスを実装するパラメーターを持ち、 +演算子をサポートする数値型であるジェネリック型の明示的な表記法を使用すると、非常に醜いものになります。 ！

現在、コードジェネレーターを使用しています。コードジェネレーターはほとんど同じですが、外部機能と同じです。

違いは、コード生成を行うための広く受け入れられている方法（ go generateを介して）は、コンパイル時ではなく、コミット/開発時に発生することです。 コンパイル時に実行すると、コンパイラで任意のコードを実行できるようにする必要があります。ライブラリによってコンパイル時間が桁違いに大きくなる可能性があります。また、ビルドの依存関係が個別になります（つまり、Goだけではコードをビルドできなくなります）。道具）。 私は、メタプログラミングの呼び出しを上流の開発者にプッシュするためのGoが好きです。

つまり、これらの問題を解決するためのすべてのアプローチと同様に、このアプローチにも欠点があり、トレードオフが伴います。 個人的には、型システムでサポートされている実際のジェネリックは、より優れている（つまり、より強力な機能セットを備えている）だけでなく、予測可能で安全なコンパイルの利点を保持している可能性があると主張します。

上記のすべてを読みますが、約束しますが、少し追加します-ApacheBeam用のGoLangSDKは、ライブラリ設計者が高レベルのものを適切に実行するために耐えなければならない問題のかなり明るい例/ショーケースのようです。

Goジェネリックには少なくとも2つの実験的な実装があります。 今週の初めに、私は（1）でしばらく過ごしました。 コードの読みやすさへの影響が最小限であることがわかり、うれしく思いました。 そして、同等性テストを提供するための匿名関数の使用がうまく機能していることがわかりました。 したがって、演算子のオーバーロードは必要ないと確信しています。 私が見つけた1つの問題は、エラー処理にありました。 「returnnil、err」の一般的なイディオムは、型が整数または文字列などの場合は機能しません。 これを回避する方法はいくつかありますが、すべて複雑なコストがかかります。 私は少し奇妙かもしれませんが、Goのエラー処理は好きです。 したがって、これにより、Goジェネリックソリューションには、型のゼロ値に対するユニバーサルキーワードが必要であることがわかります。 コンパイラは、数値型の場合はゼロ、文字列型の場合は空の文字列、構造体の場合はnilに置き換えるだけです。

この実装はパッケージレベルのアプローチを強制しませんでしたが、そうするのは確かに自然なことです。 そしてもちろん、この実装は、コンパイラーがインスタンス化したコードをどこに置くべきか（どこにでもある場合）、コードデバッガーがどのように機能するかなどに関するすべての技術的な詳細に対応していませんでした。

整数とポイントのようなものに同じアルゴリズムコードを使用するのは非常に良かったです。

type Point struct {
    x,y int
}

私のテストと観察については（2）を参照してください。

（1） https://github.com/albrow/fo; もう1つは、前述のhttps://github.com/cosmos72/gomacro#genericsです。
（2） https://github.com/mandolyte/fo-experiments

@mandolyte *new(T)を使用して、任意のタイプのゼロ値を取得できます。

default（T）やzero（T）のような言語構造（最初のものは1つです
C＃IIRCでは）は明らかですが、OTOHは* new（T）よりも長くなります（ただし、
パフォーマンス）。

2018-07-06 9:15 GMT-05：00 Tom [email protected]：

@mandolyte https://github.com/mandolyte * new（T）を使用して
任意のタイプのゼロ値。

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment-403046735 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AlhWhQ5cQwnc3x_XUldyJXCHYzmr6aN3ks5uD3ETgaJpZM4IG-xv
。

-
これは、TripleMintで使用されるメール署名のテストです。

19642は一般的なゼロ値を議論するためのものです

@tmthrgdどういうわけか私はその小さな一口を逃した。 ありがとう！

プレリュード

ジェネリックスとは、カスタマイズ可能な構成を特殊化することです。 専門分野の3つのカテゴリは次のとおりです。

• 特殊なタイプ、 Type<T> -_ array_;
• 特殊な計算、 F<T>(T)またはF<T>(Type<T>) -_ sortable array_;
• 特殊な表記法、たとえば_LINQ_-Goのselectまたはforステートメント。

もちろん、さらに一般的な構造を提示するプログラミング言語もあります。 しかし、_C ++ _、_ C＃_、または_Java_のような従来のプログラミング言語は、このリストに限定された多かれ少なかれ言語構造を提供します。

考え

ジェネリック型/コンストラクトの最初のカテゴリーは、型に依存しない必要があります。

ジェネリック型/コンストラクトの2番目のカテゴリーは、型パラメーターの_property_に_作用_する必要があります。 たとえば、_sortable array_は、そのアイテムの_comparableプロパティ_を_compare_できる必要があります。 T.(P)がTのプロパティであり、 A(T.(P))がそのプロパティに作用する計算/アクションであると仮定すると、 (A, .(P))は個々のアイテムのいずれかに適用できます。または、特殊な計算として宣言され、元のカスタマイズ可能な計算に渡されます。 Goの後者の場合の例は、対応する個別の関数sort.Reverseも持つsort.Interfaceインターフェースです。

ジェネリック型/構成の3番目のカテゴリーは、_type-specialized_言語表記法です-一般的にはGoのものではないようです。

質問

つづく ...

絵文字よりもわかりやすいフィードバックは大歓迎です。

@ dc0dジェネリックスを定義する前に、Sepanovの「ElementsofProgramming」を勉強することをお勧めします。 TL; DRは、配列を並べ替えるアルゴリズムなど、最初に具体的なコードを記述します。 後で、Btreeなどの他のコレクションタイプを追加します。本質的に同じソートアルゴリズムのコピーを多数作成していることに気付いたので、「ソート可能」などの概念を定義します。 ここで、ソートアルゴリズムを分類します。たとえば、転送のみ、シングルパス（ストリーム）、マルチパスのみの転送（単一リンクリスト）、双方向（二重リンクリスト）、ランダムアクセス（配列）。 新しいコレクションタイプを追加するときは、関連するすべての並べ替えアルゴリズムにアクセスするために、どのカテゴリの「座標」に分類されるかを指定するだけで済みます。 これらのアルゴリズムカテゴリは、「Go」インターフェイスによく似ています。 Goのインターフェースを拡張して、複数の型パラメーターと抽象/関連型をサポートすることを検討しています。 関数にはアドホックタイプのパラメーター化は必要ないと思います。

@ dc0dジェネリックスをコンポーネント部分に分割する試みとして、私は3、「特殊表記」をそれ自体の別個の部分とは考えていませんでした。 おそらく、型制約を利用してDSLを定義することとして特徴付けることができます。

あなたの1と2は、それぞれ「データ構造」と「アルゴリズム」であると私は主張するかもしれません。 その用語を使用すると、それらが互いに非常に依存していることが多いため、それらをきれいに分離することが難しい理由が少し明確になります。 しかし、sort.Interfaceは、保存と動作の間に線を引くことができる非常に良い例です（少し最近の砂糖を使用して、より良いものにします）。これは、並べ替えアルゴリズムを実装するために必要な最小限の動作にIndexableおよびComparableの要件をエンコードするためです。 「swap」と「less」（およびlen）を使用します。 しかし、これはツリーやヒープなどのより複雑なデータ構造に分解されているようです。どちらも現在、Goインターフェイスとしての純粋な動作にマッピングするためにいくつかのゆがみがあります。

ほとんどの教科書のデータ構造とアルゴリズムをゆがみなく（sort.Interfaceが今日のように）比較的クリーンに実装できるようにするが、DSLを設計するのに十分強力ではない、インターフェイス（またはその他）への比較的小さなジェネリックスの追加を想像できます。 ジェネリックスを追加するというすべての問題に直面するときに、そのような制限されたジェネリックスの実装に自分自身を制限したいかどうかは別の問題です。

二分木の@infogulch座標構造は「分岐座標」であり、他のツリーにも同等のものが存在します。 ただし、事前注文、注文中、注文後の3つの注文のいずれかを使用してツリーの順序を予測することもできます。 これらのいずれかを決定すると、ツリーは双方向座標としてアドレス指定でき、双方向座標で定義されたソートアルゴリズムのファミリーが最適に効率的になります。

重要なのは、アクセスパターンによってソートアルゴリズムを分類することです。 各アクセスパターンに最適なソートアルゴリズムは有限数しかありません。 この時点では、データ構造は気にしません。 より複雑な構造について話すことは要点を見逃します。データ構造ではなく、ソートアルゴリズムのファミリーを分類したいと思います。 持っているデータが何であれ、それをソートするために存在するアルゴリズムの1つを使用する必要があるため、ソートアルゴリズムの利用可能なデータアクセスパターン分類のどれが、持っているデータ構造に最適であるかが問題になります。

（私見では）

@infogulch

おそらく、型制約を利用してDSLを定義することとして特徴付けることができます。

あなたが正しいです。 しかし、それらは一連の言語構造の一部であるため、IMOがそれらをDSLと呼ぶのは少し不正確です。

1と2 ...は多くの場合非常に依存しています

再び真実。 しかし、実際の使用法はまだ決定されていませんが、プログラムのその時点で、コンテナタイプを渡す必要がある場合が多くあります。 そのため、1を単独で学習する必要があります。

sort.Interfaceは、_storage_と_behavior_の間に線を引くことができる非常に良い例です。

よく言われます。

これは、より複雑なデータ構造に分解されるようです

それは私の質問の1つです：タイプパラメータを一般化して制限（ List<T> where T:new, IDisposableなど）の観点から説明するか、（セットの;特定のタイプの）すべてのアイテムに適用できる一般化された_プロトコル_を提供しますか？

@keean

問題は、ソートアルゴリズムの利用可能なデータアクセスパターン分類のどれがあなたが持っているデータ構造に最適であるかということです。

本当です。 インデックスによるアクセスは、スライス（または配列）の_プロパティ_です。 したがって、ソート可能なコンテナー（または_tree_アルゴリズムが何であれ_tree_可能なコンテナー）の最初の要件は、_access＆mutate（swap）_ユーティリティを提供することです。 2番目の要件は、アイテムが比較可能でなければならないことです。 これは、アルゴリズムと呼ばれるものについて（私にとって）紛らわしい部分です。要件は、両側（コンテナーとタイプパラメーター）で満たされる必要があります。 それが、Goでのジェネリックスの実用的な実装を想像できないポイントです。 問題の各側面は、インターフェースの観点から完全に説明できます。 しかし、これら2つを効果的な表記法で組み合わせるにはどうすればよいでしょうか。

@ dc0dアルゴリズムにはインターフェースが必要であり、データ構造がそれらを提供します。 インターフェイスが十分に強力であれば、これで十分に一般化できます。 インターフェイスは型によってパラメータ化されますが、型変数が必要です。

'sort'の例をとると、 'Ord'はコンテナ自体ではなく、コンテナに格納されているタイプのプロパティです。 アクセスパターンはコンテナのプロパティです。 単純なアクセスパターンは「イテレータ」ですが、その名前はC ++に由来し、Stepanovは、より複雑な多次元コンテナに適用できるため、「座標」を優先しました。

並べ替えを定義しようとすると、次のようなものが必要になります。

bubble_sort : forall T U I => T U -> T U requires
   ForwardIterator<T>, Readable<T>, Writable<T>,
   Ord<U>,  ValueType(T) == U, Distance type(T) == I

注：私はこの表記法を提案していません。他の関連する作業を取り込もうとしています。requires句はStepanovが推奨する構文であり、関数型はHaskellのものであり、その型クラスはおそらくこれらの概念の優れた実装を表しています。

@keean
誤解しているかもしれませんが、少なくとも現在のインターフェースの定義方法では、アルゴリズムをインターフェースのみに制限することはできないと思います。
たとえば、sort.Sliceについて考えてみましょう。スライスの並べ替えに関心があり、すべてのスライスを表すインターフェイスを構築する方法がわかりません。

@urandomは、コレクションではなくアルゴリズムを抽象化します。 したがって、「ソート」アルゴリズムにどのようなデータアクセスパターンが存在するかを尋ね、それらを分類します。 したがって、コンテナが「スライス」であるかどうかは関係ありません。スライスで実行する可能性のあるすべての操作を定義しようとしているのではなく、アルゴリズムの要件を決定し、それを使用してインターフェイスを定義しようとしています。 スライスは特別なものではなく、一連の操作を定義できるのはタイプTだけです。

したがって、インターフェイスはアルゴリズムのライブラリに関連しており、それらのアルゴリズムを使用できるようにするために、独自のデータ構造に対して独自のインターフェイスを定義できます。 ライブラリには、組み込み型用の事前定義されたインターフェイスが付属している場合があります。

@keean
それがあなたの言っていることだと思いました。 しかし、Goのコンテキストでは、それはおそらく、インターフェースが定義できるものの大幅なオーバーホールが必要になることを意味します。 sort.Sliceやmath.Maxなどをインターフェイス上で汎用化するには、反復や演算子などのさまざまな組み込み演算をメソッドを介して公開する必要があると思います。

したがって、次のインターフェイス（擬似コード）をサポートする必要があります。

type [T] OrderedIterator interface {
   Len() int
   ValueAt(i int) *T
}

...
package sort

func [T] Slice(s [T]OrderedIterator, func(i, j int) bool) {
   ...
}

そして、すべてのスライスにこれらのメソッドがありますか？

@urandomイテレータはコレクションの抽象化ではなく、コレクションへの参照/ポインタの抽象化です。 たとえば、フォワードイテレータは単一のメソッド「successor」（場合によっては「next」）を持つことができます。 イテレータの場所でデータにアクセスできることは、イテレータのプロパティではありません（そうしないと、イテレータの読み取り/書き込み/変更可能なフレーバーになってしまいます）。 「参照」を読み取り可能、書き込み可能、​​および変更可能なインターフェースとして個別に定義することをお勧めします。

type T ForwardIterator interface {
   type DistanceType D
   successor(x T) T
}

type T Readable interface {
   type ValueType U 
   source(x T) U
}

注：タイプ「T」はスライスではなく、スライス上のイテレーターのタイプです。 開始と終了のイテレータをsortなどの関数に渡すC ++スタイルを採用している場合、これは単なるポインタになります。

ランダムアクセスイテレータの場合、次のようになります。

type T RandomIterator interface {
   type DistanceType D
   setPosition(x DistanceType)
}

したがって、イテレータ/座標は、コレクション自体ではなく、コレクションへの参照を抽象化したものです。 イテレータを座標、コレクションをマップと考えると、「座標」という名前はこれを非常にうまく表現しています。

関数クロージャや無名関数を利用しないことでGoshortを販売していませんか？ Goのファーストクラスタイプとして関数/メソッドを使用すると役立つ場合があります。 たとえば、 albrow / foの構文を使用すると、バブルソートは次のようになります。

type SortableContainer[C,T] struct {
    Less func(C,T,T) bool
    Swap func(C,int,int)
    Next func(C) (T,bool)
}

func (bs *SortableContainer[C,T]) BubbleSort(container C, e1,e2 T) {    
    swapCount := 1
    var item1, item2 T
    item1, ok1 = bs.Next()
    if !ok1 {return}
    item2, ok2 = bs.Next()
    if !ok2 {return}
    for swapCount > 0 {
        swapCount = 0
        for {
            if Less(item2, item1) { 
                bs.Swap(C,item2,item1)
                swapCount += 1
            }
        }
    }
}

間違いを見逃してください...完全にテストされていません！

@mandolyteこれが私に宛てられたものかどうかわかりませんか？ マルチパラメータインターフェイスを使用していることと、抽象/関連付けられた型を使用して例を示していることを除いて、私が提案したものとあなたの例の間に違いは実際にはわかりません。 明確にするために、完全な一般性のためにマルチパラメータインターフェイスと抽象/関連タイプの両方が必要だと思います。どちらも現在Goではサポートされていません。

並べ替え順序、アクセスパターン、およびアクセシビリティを同じインターフェイスに結び付けるため、インターフェイスは私が提案したものよりも一般的ではないことをお勧めします。これにより、もちろん、インターフェイスが急増します。たとえば、2つの順序（ 、より大きい）、3つのアクセスタイプ（読み取り専用、書き込み専用、可変）および5つのアクセスパターン（フォワードシングルパス、フォワードマルチパス、双方向、インデックス付き、ランダム）は、11のみであるのに対し、36のインターフェイスになります。懸念が分離されている場合。

次のような抽象型の代わりに、マルチパラメータインターフェイスを使用して提案するインターフェイスを定義できます。

type I ForwardIterator interface {
   successor(x I) I
}
type R V Readable interface {
   source(x R) V
}
type V Ord interface {
   less(x V, y V) : bool
}

2つのタイプパラメータを必要とするのはReadableインターフェイスだけであることに注意してください。 ただし、イテレータオブジェクトが反復されるオブジェクトの型を「含む」能力を失います。これは、型システム内で「値」型を移動する必要があり、正しく取得する必要があるため、大きな問題です。 。 これにより、タイプパラメータが急増しますが、これは適切ではなく、コーディングエラーの可能性が高くなります。 また、イテレータで「DistanceType」を定義する機能も失われます。これは、コレクション内の要素をカウントするために必要な最小の数値型であり、int8、int16、int32などにマッピングして必要な型を指定するのに役立ちます。オーバーフローなしで要素をカウントします。

これは、「機能依存性」の概念と密接に関連しています。 タイプが別のタイプに機能的に依存している場合、それは抽象/関連タイプである必要があります。 2つのタイプが独立している場合にのみ、それらは別々のタイプパラメーターである必要があります。

いくつかの問題：

1. マルチパラメータインターフェイスに現在のf（x I）構文を使用することはできません。 とにかく、この構文がインターフェイス（型の制約）と型を混同するのは好きではありません。
2. パラメータ化された型を宣言する方法が必要になります。
3. 与えられたタイプパラメータのセットを使用して、インターフェイスに関連付けられたタイプを宣言する方法が必要になります。

@keeanインターフェイスの数が非常に多くなる方法や理由がわかりません。 完全に機能する例を次に示します。https ：//play.folang.org/p/BZa6BdsfBgZ（スライスベースであり、一般的なコンテナではないため、Next（）メソッドは必要ありません）。

1つのタイプの構造体のみを使用し、インターフェイスはまったく使用しません。 すべての無名関数とクロージャを提供する必要があります（おそらくトレードオフはここにありますか？）。 この例では、同じバブルソートアルゴリズムを使用して、整数のスライスと「（x、y）」ポイントのスライスの両方をソートします。ここで、原点からの距離は、Less（）関数の基礎です。

とにかく、型システムに関数を持たせることがどのように役立つかを示したいと思っていました。

@mandolyte私はあなたが提案していることを誤解したと思います。 あなたが話しているのは「folang」で、すでにいくつかの関数型プログラミング機能がGoに追加されています。 実装したのは、基本的にマルチパラメータ型クラスを手動で配管することです。 関数ディクショナリと呼ばれるものをソート関数に渡します。 これは、インターフェースが暗黙的に行うことを明示的に行っています。 これらの種類の機能は、マルチパラメータインターフェイスおよび関連する型の前におそらく必要ですが、最終的には、これらすべてのディクショナリを渡す際に問題が発生します。 インターフェイスは、よりクリーンで読みやすいコードを提供すると思います。

スライスの並べ替えは解決された問題です。 これは、 go-li（golangが改善された）言語を使用して実装されたスライスquicksort.goのコードです。

func main(){
    var data = []int{5,3,1,8,9}

    Sort(data, func(a *int, b *int) int {
        return *a - *b
    })

    fmt.Println(data)
}

あなたは遊び場でこれを試すことができます

クイックソートパッケージのインポートはプレイグラウンドでは機能しないため、完全な例をプレイグラウンドに貼り付けることができます。

@ go-liス​​ライスを並べ替えることができると確信しています。できなければ、少し貧弱になります。 重要なのは、一般的に、同じコードで任意の線形コンテナーをソートできるようにすることです。これにより、ソートするコンテナー（データ構造）や、コンテンツはです。

これを実行できる場合、標準ライブラリはユニバーサルソート関数を提供でき、誰もそれを再度作成する必要はありません。 これには2つの利点があります。正しい並べ替えアルゴリズムを作成するのは思ったより難しいため、間違いが少なくなります。Stepanovは、ほとんどのプログラマーが「min」と「max」のペアを正しく定義できないという例を使用しています。より複雑なアルゴリズムを修正します。 もう1つの利点は、各ソートアルゴリズムの定義が1つしかない場合に、それを使用するすべてのプログラムに利益をもたらすことができる明快さまたはパフォーマンスの改善です。 人々は、異なるデータ型ごとに独自のアルゴリズムを作成する代わりに、共通のアルゴリズムを改善するために時間を費やすことができます。

@keean
以前の議論に関連する別の質問。 アイテムをイテラブルから変更し、アイテムが元のタイプとは異なる可能性がある新しい具象イテラブルタイプを返すマッピング関数をどのように定義できるかわかりません。

そして、そのような関数のユーザーは、別のインターフェースではなく、具体的な型を返したいと思うでしょう。

@urandom安全ではない「インプレース」で実行するつもりはないと仮定すると、必要なのは、あるタイプの「読み取りイテレータ」と別のタイプの「書き込みイテレータ」を持つマップ関数です。これは次のように定義できます。

map<I, O, U>(first I, last I, out O, fn U) requires
   ForwardIterator<I>, Readable<I>,
   ForwardIterator<O>, Writable<O>,
   UnaryFunction<U>, Domain(U) == ValueType(I), Codomain(U) == ValueType(O)

わかりやすくするために、「ValueType」は「Readable」および「Writable」インターフェースの関連タイプであり、「Domain」および「Codomain」は「UnaryFunction」インターフェースの関連タイプです。 コンパイラが「UnaryFunction」のようなデータ型のインターフェイスを自動的に導出できる場合は、明らかに非常に役立ちます。 この種のリフレクションのように見えますが、そうではなく、すべて静的型を使用してコンパイル時に発生します。

@keean現在のGoのインターフェースのコンテキストで、これらの読み取り可能および書き込み可能な制約をモデル化する方法は？

つまり、タイプAがあり、タイプBに変換する場合、そのUnaryFunctionのシグネチャはfunc (input A) Bになります（右？）が、どうすればよいでしょうか。インターフェイスのみを使用してモデル化され、その汎用map （またはfilter 、 reduceなど）が型のパイプラインを維持するためにどのようにモデル化されますか？

@ geovanisouza92 「型族」は、型システムの直交メカニズムとして実装でき、Haskellで行われているように、インターフェースの構文に統合できるので、うまく機能すると思います。

型族は、型の制限された関数（マッピング）のようなものです。 インターフェイスの実装はタイプごとに選択されるため、実装ごとにタイプマッピングを提供できます。

したがって、次のように定義します。

ValueType MyIntArrayIterator -> Int

関数は少しトリッキーですが、関数には次のようなタイプがあります。

fn(x : Int) Float

このタイプを書きます：

Int -> Float

->は単なる中置型コンストラクターであり、配列の '[]'は型コンストラクターであるため、これを簡単に記述できることを理解することが重要です。

Fn Int Float
Or
Fn<Int, Float>

型構文の好みに応じて。 これで、次のように定義する方法が明確にわかります。

Domain  Fn<Int, Float> -> Int
Codomain Fn<Int, Float> -> Float

これらすべての定義を手動で提供できるようになりましたが、コンパイラーによって簡単に導出できます。

これらの型族を考えると、他のすべての型は機能的にこれらに依存しているため、上記のマップの定義では、ジェネリックをインスタンス化するために型IOとUのみが必要であることがわかります。 これらの型は引数によって直接提供されていることがわかります。

ありがとう、@ keean。

これは、組み込み/事前定義された関数に対しては正常に機能します。 同じ概念がユーザー定義関数またはユーザーランドライブラリに適用されると言っていますか？

これらの「タイプファミリー」は、エラーコンテキストの場合、実行時に実行されますか？

空のインターフェース、タイプスイッチ、リフレクションはどうですか？

編集：私は不平を言うのではなく、ただ興味があります。

@ giovanisouza92誰もジェネリックを持って行くことを約束していないので、私は懐疑論を期待しています。 私のアプローチは、ジェネリックスを実行する場合は、正しく実行する必要があるというものです。

私の例では、「マップ」はユーザー定義です。 特別なことは何もありません。関数内では、現在Goで行うのとまったく同じように、これらの型で必要なインターフェイスのメソッドを使用するだけです。 唯一の違いは、複数のインターフェースを満たすために型を要求できること、インターフェースは複数の型パラメーターを持つことができること（ただし、マップの例ではこれを使用していません）、関連する型（および型の等式 '=='などの型に対する制約）もあることです。しかし、これはプロローグの同等性のようなものであり、型を統一します）。 これが、関数に必要なインターフェースを指定するための異なる構文がある理由です。 別の重要な違いがあることに注意してください。

f(x I, y I) requires ForwardIterator<I>

対

f(x ForwardIterator, y ForwardIterator)

後者には違いがあることに注意してください。「x」と「y」はForwardIteratorインターフェースを満たす異なるタイプである可能性がありますが、前者の構文では「x」と「y」は両方とも同じタイプである必要があります（フォワードイテレーターを満たす）。 これは、関数に制約が不足しないようにするために重要であり、コンパイル中に具象型をさらに伝播できるようにします。

インターフェイスの概念を拡張しているだけなので、タイプスイッチとリフレクションに関しては何も変わらないと思います。 goには実行時型情報があるため、Haskellと同じ問題は発生せず、存在型が必要です。

Go、実行時のポリモーフィズム、および型ファミリーについて考えると、実行時に関連するすべての型を空のインターフェイスとして扱う必要がないように、型ファミリー自体をインターフェイスに制限する必要があります。

したがって、これらの考えに照らして、上記の提案を変更し、インターフェイスを宣言するときに、関連付けられたタイプごとにインターフェイス/タイプを宣言し、そのインターフェイスのすべての実装がそのインターフェイスを満たす関連付けられたタイプを提供する必要があるようにします。 このようにして、空のインターフェイスから型を切り替えることなく、実行時に関連する型でそのインターフェイスからメソッドを呼び出すことが安全であることがわかります。

@keean
議論を進めるために、私が感じている誤解を明確にさせてください。ここで発明されていない症候群が起こっているのと似ています。

双方向イテレータ（T構文func (*T) *[2]*T ）のタイプは、go-li構文でfunc (*) *[2]*です。 つまり、あるタイプへのポインターを受け取り、同じタイプの次の要素と前の要素への2つのポインターへのポインターを返します。 これは、二重リンクリストで使用される基本的な具体的な基本タイプです。

これで、マップと呼ばれるもの、つまりforeachジェネリック関数と呼ばれるものを記述できます。 間違いなく、これはリンクリストだけでなく、双方向イテレータを公開するすべてのものに対して機能します。

func Foreach(link func(*) *[2]*, list **, direction byte, f func(*)) {

    if nil == *list {
        return
    }

    var end *
    end = *list

    var e *
    e = (*link(*list))[direction]
    f(end)

    for (e != end) && ((*link(e))[direction] != nil) {
        var newe = (*link(e))[direction]
        f(e)
        e = newe
    }
    return
}

Foreachは、2つの方法で使用できます。つまり、リストまたはコレクション要素に対するforループのような反復でラムダを使用します。

const forward = 1
const backwards = 0
Foreach(iterator, collection, forward, func(element *element_type){
    // do something with every element
})

または、これを使用して、関数をすべてのコレクション要素に機能的にマップすることもできます。

Foreach(iterator, collection, backwards, function_to_be_mapped_on_elements)

もちろん、双方向イテレータは、go1のインターフェイスを使用してモデル化することもできます。
interface Iterator { Iter() [2]Iterator }基になる型をラップ（「ボックス」）するには、インターフェースを使用してモデル化する必要があります。 次に、イテレータユーザーは、特定のコレクション要素を見つけてアクセスしたい場合に、既知の型をアサートします。 これは、コンパイル時に安全でない可能性があります。

次に説明するのは、レガシーアプローチとジェネリックベースのアプローチの違いです。

func modern(x func  (*) *[2]*, y func  (*) *[2]*){}

このアプローチのコンパイル時型は、2つのコレクションが同じ基になる型を持っているかどうか、つまり、イテレーターが実際に同じ具象型を返すかどうかをチェックします。

func modern_T_syntax<T>(x func  (*T) *[2]*T, y func  (*T) *[2]*T){}

上記と同じですが、使い慣れたTを使用すると、タイププレースホルダー構文を意味します

func legacy(x Iterator, y Iterator){}

この場合、ユーザーは、たとえば整数リンクリストをxとして、浮動小数点リンクリストをyとして渡すことができます。 これは、潜在的な実行時エラー、パニック、またはその他の内部デコヒーレンスにつながる可能性がありますが、それはすべて、レガシーが2つのイテレーターで何をするかに依存します。

今誤解。 あなたは、イテレータを実行し、それらのイテレータをソートするために一般的なソートを実行することが、進むべき道であると主張します。 それは本当に悪いことです、これが理由です

イテレータとリンクリストは同じコインの表裏です。 証明：イテレータを公開するコレクションは、リンクリストとして自分自身をアドバタイズするだけです。 それを並べ替える必要があるとしましょう。 何をしますか？

明らかに、リンクリストをコードベースから削除し、バイナリツリーに置き換えます。 または、提案されているように、avl、red-blackなどのバランスの取れた検索ツリーを使いたい場合は、Ian etallによって何年前かわかりません。 それでも、これはgolangでは一般的に行われていません。 さて、それが進むべき道です。

別の解決策は、イテレータのO（N）タイムループですばやく、要素へのポインタを[]*Tで示されるジェネリックポインタのスライスに収集し、貧弱なスライスソートを使用してそれらのジェネリックポインタをソートすることです。

他の人のアイデアにチャンスを与えてください

@ go-liここで発明されていない症候群を避けたい場合は、ジェネリックプログラミングをほとんど発明したアレックスステパノフに定義を求める必要があります。 Stepanovの「ElementsofProgramming」111ページから引用して、これを定義する方法は次のとおりです。

Bidirectional iterator<T> =
    ForwardIterator<T>
/\ predecessor : T -> T
/\ predecessor takes constant time
/\ (forall i in T) successor(i) is defined =>
        predecessor(successor(i)) is defined and equals i
/\ (forall i in T) predecessor(i) is defined =>
        successor(predecessor(i)) is defined and equals i

これは、ForwardIteratorの定義によって異なります。

ForwardIterator<T> =
    Iterator<T>
/\ regular_unary_function(successor)

つまり、基本的に、 successor関数とpredecessor関数を宣言するインターフェースと、それらが有効であるために準拠しなければならないいくつかの公理があります。

legacyに関しては、レガシーがうまくいかないわけではなく、現在Goでも明らかにうまくいかないが、コンパイラーには最適化の機会がなく、型システムには具体的な型をさらに伝播する機会がない。 また、プログラマーが意図を正確に指定することを制限しています。 例としては、恒等関数があります。これは、渡された型を正確に返すことを意味します。

id(x T) T

おそらく、パラメトリックタイプと全称記号タイプの違いについても言及する価値があります。 パラメトリックタイプはid<T>(x T) Tですが、全称記号はid(x T) Tです（この場合、通常、最も外側の全称記号はforall Tを省略します）。 パラメトリック型の場合、型システムはコールサイトでidのT型を提供する必要があり、コンパイルが完了する前にTが具象型と統合される限り、全称記号は必要ありません。 これを理解する別の方法は、パラメトリック関数が型ではなく型のテンプレートであり、Tが具象型に置き換えられた後にのみ有効な型であるということです。 全称記号関数を使用すると、 idは実際にはforall T . T -> T型になり、 Intと同じようにコンパイラーが渡すことができます。

@ go-li

明らかに、リンクリストをコードベースから削除し、バイナリツリーに置き換えます。 または、提案されているように、avl、red-blackなどのバランスの取れた検索ツリーを使いたい場合は、Ian etallによって何年前かわかりません。 それでも、これはgolangでは一般的に行われていません。 さて、それが進むべき道です。

データ構造を並べ替えても、データを並べ替える必要がないという意味ではありません。

ここで発明されていない症候群を避けたい場合は、アレックス・ステパノフがジェネリックプログラミングをほとんど発明したので、定義を探す必要があります。

私は、ジェネリックプログラミングがC ++によって発明されたという主張に異議を唱えます。 Liskov etalを読んでください。 実際に機能するジェネリックプログラミングの初期モデル（タイプセーフ、モジュラー、コード膨張なし）を確認したい場合は、1977年のCACMペーパー： https ：//dl.acm.org/citation.cfm？id = 359789（セクション4を参照） ）。

この議論をやめて、golangチーム（russ）がいくつかのブログ投稿を出すのを待ってから、ソリューションを実装する必要があると思います👍（vgoを参照）彼らはそれを実行します🎉

https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html

この話が他の人への警告として役立つことを願っています。Goプロジェクトに実質的な貢献をすることに興味がある場合、コアチームに由来しない設計を独立したデューデリジェンスで補うことはできません。

このスレッドは、コアチームがコミュニティで解決策を見つけることに積極的に参加することにどのように関心がないかを示しています。

しかし、結局、彼らが再び自分たちで解決策を作ることができれば、それは私には問題ありません、ただそれを成し遂げてください👍

@andrewcmyersおそらく「発明された」というのは少しストレッチでした。おそらく、1971年にAdaのいくつかの汎用ライブラリでStepanovと協力したDavidMusserに似ています。

Elements ofProgrammingはC ++に関する本ではなく、例はC ++である可能性がありますが、それは非常に異なるものです。 この本は、あらゆる言語でジェネリックスを実装したい人にとっては必読だと思います。 Stepanovを却下する前に、本を実際に読んで、実際の内容を確認する必要があります。

この問題は、GitHubのスケーラビリティの制限の下ですでに負担になっています。 Go提案の具体的な問題に焦点を当てたここでの議論を続けてください。

GoがC ++ルートをたどるのは残念なことです。

@andrewcmyersはい、私は心から同意します。構文の提案や、適切に実行するためのベンチマークとしてC ++を使用しないでください。 代わりに、インスピレーションを得るためにDをご覧ください。

@ nomad-ソフトウェア

私はDがとても好きですが、Dが提供する強力なコンパイル時のメタプログラミング機能が必要ですか？

石器時代に由来するC ++のテンプレート構文も好きではありません。

しかし、通常のParametricTypeはどうですかJavaまたはC＃にある標準。必要に応じて、これをParametricTypeでオーバーロードすることもできます。

さらに、私はそのbangシンボルを持つDのテンプレート呼び出し構文が好きではありません。bangシンボルは、関数のパラメーターへの可変または不変のアクセスを示すために最近使用されています。

@ nomad-software C ++構文またはテンプレートメカニズムがジェネリックスを実行する正しい方法であることを示唆していませんでした。 Stepanovによって定義されている「概念」は、型を代数として扱います。これは、ジェネリックスを実行するための非常に正しい方法です。 Haskellの型クラスを見て、これがどのように見えるかを確認してください。 Haskell型クラスは、何が起こっているのかを理解していれば、意味的にはc ++テンプレートと概念に非常に近いものです。

したがって、c ++構文に従わない場合は+1、型に安全でないテンプレートシステムを実装しない場合は+1 :-)

@keean D構文の理由は、 <,>を完全に回避し、文脈自由文法に従うためです。 これは、Dをインスピレーションとして使用するという私のポイントの一部です。 <,>は、ジェネリックパラメーターの構文としては非常に悪い選択です。

@ nomad-software上で指摘したように（現在は非表示のコメントで）、パラメトリック型の型パラメーターを指定する必要がありますが、全称記号型の型パラメーターは指定する必要はありません（したがって、RustとHaskellの違いにより、型の処理方法は実際には異なります型システムで）。 また、C ++の概念== Haskell型クラス==少なくとも概念レベルではGoインターフェース。

D構文は本当に望ましいですか：

auto add(T)(T lhs, T rhs) {
    return lhs + rhs;

なぜこれがC ++ / Java / Rustスタイルよりも優れているのですか？

T add<T>(T lhs, T rhs) {
    return lhs + rhs;
}

またはScalaスタイル：

T add[T](T lhs, T rhs) {
    return lhs + rhs;
}

型パラメーターの構文について考えました。 私はC ++とJavaの「山かっこ」のファンではありませんでした。なぜなら、それらは構文解析を非常に難しくし、ツールの開発を妨げるからです。 角かっこは実際には古典的な選択です（CLU、System F、およびパラメトリック多態性を備えた他の初期の言語から）。

ただし、Goの構文は非常に扱いにくいものです。おそらく、すでに非常に簡潔であるためです。 角かっこまたはかっこに基づく可能な構文は、山かっこによって導入される構文よりもさらに悪い文法上のあいまいさを作成します。 ですから、私の素因にもかかわらず、アングルブラケットは実際にはGoにとって最良の選択のようです。 （もちろん、あいまいさを生じさせない実際の山かっこもあります—⟨⟩—ただし、Unicode文字を使用する必要があります）。

もちろん、型パラメーターに使用される正確な構文は、セマンティクスを正しくすることほど重要ではありません。 その点で、C ++言語は悪いモデルです。 Genus （PLDI 2015）とFamilia （OOPSLA 2017）のジェネリックに関する私の研究グループの研究は、型クラスを拡張し、それらをインターフェースと統合する別のアプローチを提供します。

@andrewcmyersどちらの論文も興味深いと思いますが、属はオブジェクト指向であり、Goはそうではなく、Familiaはサブタイピングとパラメトリック多態性を統合しており、Goにはどちらもありません。 Goは、パラメトリックポリモーフィズムまたは全称記号のいずれかを採用する必要があると思います。サブタイピングは必要ありません。私の意見では、Goはそれを持たないためのより良い言語です。

Goは、オブジェクト指向やサブタイピングを必要としないジェネリックスを探すべきだと思います。 Goにはすでにインターフェースがあり、これはジェネリックスの優れたメカニズムだと思います。 Goインターフェース== c ++の概念== Haskell型クラスであることがわかるとしたら、「Go」のフレーバーを維持しながらジェネリックを追加する方法は、インターフェースを拡張して複数の型パラメーターを取ることだと思います（私はインターフェイスの関連する型と同様ですが、それを個別に拡張することで、複数の型パラメータを受け入れることができます）。 これが重要な変更になりますが、これを有効にするには、関数シグネチャのインターフェイスに「代替」構文が必要です。これにより、複数の型のパラメータをインターフェイスに取得できます。これにより、山かっこ構文全体が使用されます。 。

Goインターフェースは型クラスではなく、単なる型ですが、インターフェースを型クラスと統合することは、Familiaが行う方法を示しています。 GenusとFamiliaのメカニズムは、完全にオブジェクト指向である言語に結び付けられていません。 Goインターフェースは、すでにGoを重要な方法で「オブジェクト指向」にしているので、アイデアを少し単純化した形で適応させることができると思います。

@andrewcmyers

Goインターフェースは型クラスではなく、単なる型です。

それらはポリモーフィズムを可能にするので、私には型のように振る舞いません。 Addable []のようなポリモーフィック配列のオブジェクトは、実際の型（ランタイムリフレクションで表示）を保持しているため、単一パラメーター型クラスとまったく同じように動作します。 それらが型署名の型の代わりに配置されるという事実は、型変数を省略した単なる省略表記です。 表記法とセマンティクスを混同しないでください。

f(x : Addable) == f<T>(x : T) requires Addable<T>

もちろん、このIDは、単一パラメーターのインターフェースに対してのみ有効です。

インターフェイスと単一パラメータ型クラスの唯一の重要な違いは、インターフェイスがローカルで定義されることですが、これは、Haskellが型クラスで抱えるグローバルコヒーレンスの問題を回避するために役立ちます。 これはデザイン空間の興味深い点だと思います。 マルチパラメータインターフェイスは、ローカルであるという利点を備えたマルチパラメータ型クラスのすべての機能を提供します。 Go言語に継承やサブタイピングを追加する必要はありません（これは、OOを定義する2つの重要な機能です）。

私見では：

タイプ制限の表現専用のDSLよりも、デフォルトのタイプを使用する方が望ましいでしょう。 関数f(s T fmt.Stringer)を持っているようなものです。これは、 fmt.Stringerインターフェイスであるすべての型を受け入れるジェネリック関数です。

このようにして、次のようなジェネリック関数を持つことができます。

func add(a, b T int) T int {
    return a + b
}

これで、関数add()は、 intのように+演算子をサポートする任意のタイプのTで機能します。

@ dc0d現在のGo構文を見ると魅力的だと思います。 ただし、ジェネリックスに必要なすべての制約を表すことができないという点で「完全」ではなく、これをさらに拡張する必要があります。 これにより、単純さの目標と矛盾していると私が考えるさまざまな構文が急増します。 私の見解では、シンプルさはシンプルではなく、最もシンプルである必要がありますが、それでも必要な表現力を提供します。 現在、一般的な表現力におけるGoの主な制限は、マルチパラメーターインターフェイスの欠如です。 たとえば、コレクションインターフェイスは次のように定義できます。

type T U Collection interface {
   member(c T, v U) Bool
   insert(c T, v U) T
}

それで、これは理にかなっていますか？ コレクションのようなものの上にインターフェースを書きたいと思います。 したがって、問題は、関数でこのインターフェイスをどのように使用するかです。 私の提案は次のようになります：

func[T, U] f(c T, e U) (Bool, T) requires Collection[T, U] {
   a := member(c, e)
   d := insert(c, e)
   return a, d
}

構文は単なる提案ですが、これらの概念を言語で表現できる限り、構文が何であるかは気にしません。

@keean構文をまったく気にしないと言ったら、正確ではありません。 ただし、重要なのは、すべてのジェネリックパラメーターにデフォルトの型を設定することに重点を置くことでした。 その意味で、提供されるインターフェースの例は次のようになります。

type Collection interface (T interface{}, U interface{}) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

(T interface{}, U interface{})の部分は、制約の定義に役立ちます。 たとえば、メンバーがfmt.Stringerを満たすことを意図している場合、定義は次のようになります。

type Collection interface (T fmt.Stringer, U fmt.Stringer) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

@ dc0dこれも、複数の型パラメーターで制約したいという意味で制限的です。次のことを考慮してください。

type OrderedCollection[T, U] interface
   requires Collection[T, U], Ord[U] {...}

私はあなたがパラメータの配置でどこから来ているのかわかると思います、あなたは持っていることができます：

type OrderedCollection interface(T, U)
   requires Collection(T, U), Ord(U) {...}

私が言ったように、私はほとんどの構文に慣れることができるので、構文にあまり煩わされていません。 上記から、マルチパラメータインターフェイスには括弧「（）」を使用することをお勧めします。

@keean heap.Interfaceインターフェースについて考えてみましょう。 標準ライブラリの現在の定義は次のとおりです。

type Interface interface {
    sort.Interface
    Push(x interface{}) // add x as element Len()
    Pop() interface{}   // remove and return element Len() - 1.
}

それでは、デフォルトの型を使用して、ジェネリックインターフェイスとして書き直してみましょう。

type Interface interface (T interface{}) {
    sort.Interface
    Push(x T) // add x as element Len()
    Pop() T   // remove and return element Len() - 1.
}

これは、そこにあるGo1.xコードシリーズのどれも壊しません。 1つの実装は、タイプエイリアスの再バインドに関する私の提案です。 しかし、もっと良い実装があると確信しています。

デフォルトの型を使用すると、Go1.xスタイルのコードで使用できるジェネリックコードを記述できます。 そして、標準ライブラリは、何も壊すことなく、ジェネリックライブラリになることができます。 それは大きな勝利のIMOです。

@ dc0dなので、段階的な改善を提案していますか？ あなたが提案していることは、段階的な改善として私には問題ないように見えますが、それでも一般的な表現力は限られています。 「Collection」および「OrderedCollection」インターフェースをどのように実装しますか？

いくつかの部分的な言語拡張は、可能な限り単純な方法で完全なソリューションを実装するよりも、（複数の代替構文を含む）より複雑な最終製品につながる可能性があることを考慮してください。

@keean requires Collection[T, U], Ord[U]の部分がわかりません。 タイプパラメータTとUをどのように制限していますか？

@ dc0dこれらは関数の場合と同じように機能しますが、すべてに適用されます。 したがって、OrderedCollectionであるタイプTUのペアの場合、TUもCollectionのインスタンスであり、UはOrdである必要があります。 したがって、OrderedCollectionを使用する場合は、必要に応じてCollectionおよびOrdのメソッドを使用できます。

ミニマリストの場合、これらは必要ありません。必要な関数型に追加のインターフェイスを含めることができるためです。たとえば、次のようになります。

type OrderedCollection interface(T, U)
{
   first(c T) U
}

func[T] first(c T[]) T requires Collection(T[], T), Ord T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T), Collection(T[], T), Ord(T)
{...}

しかし、これはもっと読みやすいかもしれません：

type OrderedCollection interface(T, U) 
   requires Collection(T, U), Ord(U)
{
   first(c T) U
}

func[T] first(c T[]) T
{...}

func[T] f(c T[]) requires OrderedCollection(T[], T)
{...}

@keean （IMO）型パラメーターに必須のデフォルト値がある限り、私は満足しています。 このようにして、Go1.xコードシリーズとの下位互換性を維持することができます。 それが私が作ろうとした要点です。

@keean

Goインターフェースは型クラスではなく、単なる型です。

それらはポリモーフィズムを可能にするので、私には型のように振る舞いません。

はい、サブタイプのポリモーフィズムを許可します。 Goには、インターフェイスタイプを介したサブタイピングがあります。 明示的に宣言されたサブタイプ階層はありませんが、それはほぼ直交しています。 Goが完全にオブジェクト指向ではない理由は、継承がないことです。

または、インターフェイスを型クラスの存在記号アプリケーションとして表示することもできます。 それがあなたの心にあることだと思います。 それがGenusとFamiliaで行ったことです。

@andrewcmyers

はい、サブタイプのポリモーフィズムを許可します。

私が知る限り、不変であり、共分散や反変性はありません。これは、これがサブタイピングではないことを強く物語っています。 ポリモーフィック型システムは不変であるため、私にはGoがこのモデルに近いように見え、インターフェイスを単一パラメーター型クラスとして扱うことは、Goの単純さに沿っているように見えます。 共変性と反変性がないことはジェネリックスにとって大きなメリットです。C＃のような言語でそのようなものが生み出す混乱を見てください。

https://docs.microsoft.com/en-us/dotnet/standard/generics/covariance-and-contravariance

Goは、このような複雑さを完全に回避する必要があると思います。 私にとってこれは、同じ型システムでジェネリックスとサブタイピングを望まないことを意味します。

または、インターフェイスを型クラスの存在記号アプリケーションとして表示することもできます。 それがあなたの心にあることだと思います。 それがGenusとFamiliaで行ったことです。

Goは実行時に型情報を持っているため、存在記号を定量化する必要はありません。 Haskellでは型はボックス化されていません（ネイティブの「C」型のように）。これは、存在するコレクションに何かを入れたら、コンテンツの型を（簡単に）回復できないことを意味します。提供されたインターフェイス（型クラス）を使用するだけです。 ）。 これは、生データと一緒にインターフェイスへのポインタを格納することによって実装されます。 Goでは、代わりにデータのタイプが保存され、データは「ボックス化」されます（C＃のボックス化および非ボックス化データの場合と同様）。 そのため、Goはデータとともに保存されたインターフェイスだけに限定されません。コレクション内のデータのタイプを（タイプケースを使用して）回復できるためです。これは、Haskellで「Reflection」を実装することによってのみ可能です。 typeclass（データを取り出すのは面倒ですが、型とデータ、たとえば文字列をシリアル化してから、既存のボックスの外で逆シリアル化することは可能です）。 したがって、私が持っている結論は、Haskellが「Reflection」型クラスを組み込みとして提供した場合、Goインターフェイスは型クラスとまったく同じように動作するということです。 そのため、実存的なボックスはなく、コレクションの内容を活字ケースにすることはできますが、インターフェイスは型クラスとまったく同じように動作します。 HaskellとGoの違いは、ボックス化されたデータとボックス化されていないデータのセマンティクスにあり、インターフェイスは単一パラメーターの型クラスです。 実際、「Go」がインターフェースをタイプとして扱う場合、実際に実行しているのは次のとおりです。

Addable[] == exists T . T[] requires Addable[T], Reflection[T]

これは、Rustで「トレイトオブジェクト」が機能するのと同じ方法であることに注意してください。

Goは、実存主義（プログラマーに見える）、共変性、反変性を完全に回避できます。これは良いことであり、私の意見では、ジェネリックスははるかに単純で強力になります。

私が知る限り、不変であり、共分散や反変性はありません。これは、これがサブタイピングではないことを強く物語っています。

ポリモーフィック型システムは不変であるため、私にはこのモデルに近いように見え、インターフェイスを単一パラメーター型クラスとして扱うことは、Goの単純さに沿っているように見えます。

あなたが両方とも正しいことを提案してもいいですか？ その場合、インターフェイスは型クラスと同等ですが、型クラスはサブタイピングの形式です。 私がこれまでに見つけたサブタイピングの定義はすべてかなり曖昧で不正確であり、「一方を他方に置き換えることができれば、AはBのサブタイプです」に要約されます。 これ、IMOは、型クラスによって満たされると非常に簡単に主張できます。

分散引数自体は実際にはIMOとして機能していないことに注意してください。 分散は型構築子の特性であり、言語ではありません。 また、言語のすべての型構築子がバリアントであるとは限らないのはごく普通のことです（たとえば、サブタイピングを使用する多くの言語には可変配列があり、型セーフにするためには不変である必要があります）。 だから私はあなたがバリアント型コンストラクターなしでサブタイピングをすることができなかった理由がわかりません。

また、この議論はGoリポジトリの問題には少し広すぎると思います。 これは、型理論の複雑さについて議論することではなく、ジェネリックをGoに追加するかどうかとその方法について議論することです。

@Merovius Varianceは、サブタイピングに関連付けられたプロパティです。 サブタイピングのない言語では、差異はありません。 そもそも分散があるためには、サブタイピングが必要です。これにより、型構築子に共変性/反変性の問題が発生します。 ただし、サブタイピングを使用する言語では、すべての型構築子を不変にすることが可能です。

型クラスは型ではないため、型クラスは間違いなくサブタイピングではありません。 ただし、Goの「インターフェイスタイプ」は、Rustが「特性オブジェクト」と呼んでいるものと見なすことができます。事実上、タイプクラスから派生したタイプです。

Goのセマンティクスは、分散がなく、暗黙の「トレイトオブジェクト」があるため、現時点ではどちらのモデルにも適合しているようです。 したがって、おそらくGoは転換点にあり、ジェネリックスと型システムはサブタイピングのラインに沿って開発され、分散を導入し、C＃のジェネリックスのようなものになってしまう可能性があります。 あるいは、Goはマルチパラメーターインターフェイスを導入して、コレクションのインターフェイスを許可することもできます。これにより、インターフェイスと「インターフェイスタイプ」の間の直接のリンクが切断されます。 たとえば、次の場合：

type (T, U) Collection interface {
    member : (c T, e U) Bool
    insert: (c T, e U) T
}

member(c int32[], e int32) Bool {...}
insert(c int32[], e int32) int32[] {...}

member(c float32[], e float32) Bool {...}
insert(c float32[], e float32) float32[] {...}

タイプT、Uとインターフェイスコレクションの間に明らかなサブタイプの関係はなくなりました。 したがって、インスタンスタイプとインターフェイスタイプの関係は、単一パラメータインターフェイスの特殊なケースのサブタイピングとしてのみ表示でき、単一パラメータインターフェイスを使用したコレクションなどの抽象化を表現することはできません。

ジェネリックスの場合、コレクションなどをモデル化できる必要があることは明らかなので、マルチパラメーターインターフェイスは私にとって必須です。 ただし、ジェネリックスの共変性と反変性の相互作用は、過度に複雑な型システムを作成すると思うので、サブタイピングは避けたいと思います。

@keeanインターフェースは型として使用でき、型クラスは型ではないため、Goセマンティクスの最も自然な説明は、インターフェースは型クラスではないということです。 インターフェイスを型クラスとして一般化することを主張していることを理解しています。 言語を採用することは合理的な方向性だと思います。実際、私たちは公開された作品でそのアプローチをすでに広範囲にわたって調査しました。

Goにサブタイピングがあるかどうかについては、次のコードを検討してください。

package main

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = x

func main() {
    print("ok\n")
}

xからy $への割り当ては、 xのタイプが予想される場所でyのタイプを使用できることを示しています。 これはサブタイピングの関係であり、 CloneableZ <: CloneableとS <: CloneableZです。 型クラスの観点からインターフェースを説明したとしても、ここではS <: ∃T.CloneableZ[T] <: ∃T.Cloneable[T]のようなサブタイピング関係があります。

関数CloneがS $を返すことを許可することは、Goにとって完全に安全であることに注意してください。ただし、Goは、インターフェイスへの準拠のために不必要に制限的なルールを適用します。実際、Javaと同じルールです。当初は強制されました。 @Meroviusが観察したように、サブタイピングは非不変の型コンストラクターを必要としません。

@andrewcmyersコレクションを抽象化するために必要なインターフェースなど、マルチパラメーターインターフェースはどうなりますか？

さらに、xからyへの割り当ては、サブタイピングがまったくないインターフェイスの継承を示していると見なすことができます。 Haskell（明らかにサブタイピングがない）では、次のように記述します。

class Cloneable t => CloneableZ t where...

xがある場合は、 CloneableZを実装するタイプであり、定義上、 Cloneableも実装するため、明らかにyに割り当てることができます。

要約すると、インターフェイスを型として表示し、Goを使用して、共変または逆変の型コンストラクターを使用せずにサブタイピングを制限するか、「特性オブジェクト」として表示するか、Goでは「 「インターフェースオブジェクト」。これは、事実上、インターフェース「typeclass」によって制約されるポリモーフィックコンテナーです。 型クラスモデルにはサブタイプがないため、共変性と反変性について考える必要はありません。

サブタイピングモデルに固執する場合、コレクションタイプを使用することはできません。これが、オブジェクト指向のサブタイピングではコンテナなどの概念を一般的に定義するのに十分ではないため、C ++でテンプレートを導入する必要がある理由です。 抽象化のための2つのメカニズム、オブジェクトとサブタイピング、およびテンプレート/トレイトとジェネリックスになり、2つの間の相互作用は複雑になります。たとえば、C ++、C＃、およびScalaを見てください。 これらの他の言語に沿って、ジェネリックスの能力を高めるために共変および反変コンストラクターを導入するための継続的な呼びかけがあります。

別のジェネリックシステムを導入せずにジェネリックコレクションが必要な場合は、型クラスのようなインターフェイスを考える必要があります。 マルチパラメータインターフェイスは、サブタイピングについて考えるのではなく、インターフェイスの継承について考えることを意味します。 Goでジェネリックスを改善し、コレクションなどの抽象化を可能にし、C ++、C＃、Scalaなどの言語の型システムの複雑さを望まない場合は、マルチパラメーターインターフェイスとインターフェイスの継承が方法です。トーゴ。

@keean

コレクションを抽象化するために必要なインターフェイスなど、マルチパラメータインターフェイスはどうなりますか？

マルチパラメータタイプの制約をサポートするGenusとFamiliaに関する論文を参照してください。 Familiaは、これらの制約をインターフェースと統合し、インターフェースが複数のタイプを制約できるようにします。

サブタイピングモデルに固執する場合、コレクションタイプを持つことはできません

「サブタイピングモデル」の意味は完全にはわかりませんが、JavaとC＃にコレクションタイプがあることは明らかなので、この主張は私にはあまり意味がありません。

xがある場合、CloneableZを実装するタイプであり、定義上、Cloneableも実装するため、明らかにyに割り当てることができます。

いいえ、私の例では、xは変数であり、yは別の変数です。 yがCloneableZタイプで、xがCloneableタイプであることがわかっている場合、それはyからxに割り当てることができるという意味ではありません。 それが私の例がしていることです。

Goをモデル化するためにサブタイピングが必要であることを明確にするために、以下は、道徳的な同等物がHaskellでタイプチェックしない例のシャープバージョンです。 この例は、サブタイピングにより、異なる要素が異なる実装を持つ異種コレクションの作成が可能になることを示しています。 さらに、可能な実装のセットは制限がありません。

type Cloneable interface {
    Clone() Cloneable
}

type CloneableZ interface {
    Clone() Cloneable
    zero() int
}

type S struct {}

func (t S) Clone() Cloneable {
    c := t
    return c
}

type T struct { x int }

func (t T) Clone() Cloneable {
    c := t
    return c
}

func (t S) zero() int {
    return 0
}

var x CloneableZ = S{}
var y Cloneable = T{}
var a [2]Cloneable = [2]Cloneable{x, y}

@andrewcmyers

「サブタイピングモデル」の意味は完全にはわかりませんが、JavaとC＃にコレクションタイプがあることは明らかなので、この主張は私にはあまり意味がありません。

C ++がテンプレートを開発した理由を見てください。オブジェクト指向サブタイピングモデルは、コレクションなどを一般化するために必要な一般的な概念を表現できませんでした。 C＃とJavaは、オブジェクト、サブタイピング、継承とは別に完全なジェネリックシステムを導入する必要があり、次に、共変型および反変型のコンストラクターなどとの2つのシステムの複雑な相互作用の混乱をクリーンアップする必要がありました。 後知恵の恩恵を受けて、OOサブタイピングを回避し、代わりに、単純に型指定された言語にインターフェース（型クラス）を追加した場合に何が起こるかを調べることができます。 これはRustが行ったことであるため、一見の価値がありますが、もちろん、生涯を通じて複雑になります。 GoにはGCがあるので、それほど複雑ではありません。 私の提案は、Goを拡張してマルチパラメーターインターフェイスを許可し、この複雑さを回避できることです。

Haskellではこの例を実行できないというあなたの主張に関して、コードは次のとおりです。

{-# LANGUAGE ExistentialQuantification #-}

class ICloneable t where
    clone :: t -> t

class ICloneable t => ICloneableZ t where
    zero :: t

data S = S deriving Show

instance ICloneable S where
    clone x = x

data T = T Int deriving Show

instance ICloneable T where
    clone x = x

instance ICloneableZ T where
    zero = T 0

data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a

instance Show Cloneable where
    show (ToCloneable x) = show x

main = do
    x <- return S
    y <- return (T 27)
    a <- return [ToCloneable x, ToCloneable y]
    putStrLn (show a)

いくつかの興味深い違いは、Goがこのタイプdata Cloneable = forall a . (ICloneable a, Show a) => ToCloneable aを自動的に導出することです。これは、インターフェイス（ストレージがない）をタイプ（ストレージがある）に変換する方法であるためです。Rustもこれらのタイプを導出し、「特性オブジェクト」と呼びます。 。 Java、C＃、Scalaなどの他の言語では、インターフェースをインスタンス化できないことがわかります。これは実際には「正しい」ものであり、インターフェースは型ではなく、ストレージもありません。Goは、既存のコンテナーの型を自動的に取得して処理できるようにします。型のようなインターフェースであり、Goは、実存的なコンテナーに、それが派生するインターフェースと同じ名前を付けることによって、これを非表示にします。 もう1つ注意すべき点は、この[2]Cloneable{x, y}はすべてのメンバーをCloneableに強制するのに対し、Haskellにはそのような暗黙の強制はなく、 ToCloneableでメンバーを明示的に強制する必要があるということです。 。

SとTはそうではないので、 CloneableのSとTのサブタイプを考慮すべきではないことも指摘されています。構造的に互換性があります。 文字通り、任意の型をCloneableのインスタンスとして宣言でき（Goで関数cloneの関連する定義を宣言するだけで）、これらの型は互いにまったく関係がない必要があります。

Genericsの提案のほとんどには、読みやすさとGoのシンプルな感覚を損なうと思う追加のトークンが含まれているようです。 Goの既存の文法でうまく機能すると思われる別の構文を提案したいと思います（Github Markdownでは構文のハイライトもかなりうまくいきます）。

提案の要点：

• Goの文法には、探している特定のトークンまたはキーワードがあるため、型宣言がいつ終了したかを判断する簡単な方法があるようです。 これがすべての場合に当てはまる場合、型引数は型名自体の後に単純に追加できます。
• ほとんどの提案と同様に、同じ識別子はどの関数宣言でも同じ型を意味します。 これらの識別子は宣言をエスケープすることはありません。
• ほとんどの提案では、ジェネリック型の引数を宣言する必要がありますが、この提案では暗黙的です。 一部の人々は、これが読みやすさや明快さを損なう（暗黙性が悪い）、またはタイプに名前を付ける能力を制限すると主張するでしょう、反論は次のとおりです：
  
  
  
  • 読みやすさを損なうことになると、どちらの方法でも議論できると思います。または[T]は、構文上のノイズを多く発生させることで、読みやすさを損ないます。
  
  
  • 適切に使用された場合の暗黙性は、言語の冗長性を減らすのに役立ちます。 :=を使用して型宣言を常に削除します。これは、それによって隠されている情報が、毎回説明するほど重要ではないためです。
  
  
  • 具体的な（非ジェネリック）型aまたはtという名前を付けることはおそらく悪い習慣です。したがって、この提案では、これらの識別子をジェネリック型の引数として機能するように予約しても安全であると想定しています。 これにはおそらくgofixの移行が必要ですが？
  
  

package main

import "fmt"

type LinkedList a struct {
  Head *Node a
  Tail *Node a
}

type Node a {
  Next *Node a
  Prev *Node a

  Value a
}

func main() {
  // Not sure about how recursive we could get with the inference
  ll := LinkedList string {
    // The string bit could be inferred
    Head: Node string { Value: "hello world" },
  }
}

func (l *LinkedList a) Append(value a) {
  newNode := &Node{Value: value}

  if l.Tail == nil {
    l.Head = newNode
    l.Tail = l.Head
    return
  }

  l.Tail.Next = newNode
  l.Tail = l.Tail.Next
}

これは、ここで提案されている合計タイプだけでなく、もう少し詳細な要点から取得されます： https ：//gist.github.com/aarondl/9b950373642fcf5072942cf0fca2c3a2

これは完全にフラッシュされたジェネリックスの提案ではなく、そうすることを意図したものでもありません。ジェネリックスをGoに追加できるようにするために解決すべき問題がたくさんあります。 これは構文にのみ取り組むものであり、提案されたものが実行可能/望ましいかどうかについて話し合うことができることを望んでいます。

@aarondl
この構文を使用すると、私には問題ないように見えます。

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

@keean Collectionタイプについて少し説明していただけますか。 私はそれを理解できません：

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

@ dc0dコレクションは_all_コレクションを抽象化するインターフェースであるため、ツリー、リスト、スライスなど、任意のデータ型を含む任意のコレクションで機能するmemberやinsertなどの一般的な操作を実行できます。 上記では、前の例でLinkedList型に「挿入」を定義する例を示しました。

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

スライス用に定義することもできます

func insert(c []a, e a) []a {
   return append(c, e)
}

ただし、これが機能するためには、ポリモーフィック型aの@aarondlで示されているような、型変数を持つ種類のパラメトリック関数も必要ありません。具体的な型を定義するだけです。

func insert(c *LinkedList int, e int) *LinkedList int {
   c.Append(e)
   return c
}

func insert(c *LinkedList float, e float) *LinkedList float {
   c.Append(e)
   return c
}

func insert(c int[], e int) int[] {
   return append(c, e)
}

func insert(c float[], e float) float[] {
   return append(c, e)
}

したがって、 Collectionは、コンテナーのタイプとそのコンテンツのタイプの両方を一般化するためのインターフェースであり、コンテナーとコンテンツのすべての組み合わせで動作するジェネリック関数を記述できます。

コレクションのスライス[]Collectionを使用できない理由はありません。ここで、コンテンツはすべて、異なる値タイプの異なるコレクションタイプであり、組み合わせごとにmemberとinsertが定義されています。 。

@aarondl type LinkedList aがすでに有効な型宣言であることを考えると、これを明確に解析可能にする方法は2つしかわかりません。文法の文脈依存にする（Cの解析の問題に取り組む）か、無制限の先読みを使用する（失敗した場合のエラーメッセージが悪いため、go文法はこれを回避する傾向があります）。 私は何かを誤解しているかもしれませんが、トークンのないアプローチに反対するIMOです。

Goの@keeanインターフェースは、関数ではなくメソッドを使用します。 あなたが提案した特定の構文では、コンパイラーのinsertを*LinkedListに付加するものは何もありません（Haskell instance宣言を介して行われます）。 メソッドが操作している値を変更することも正常です。 これはいずれもShow-Stopperではなく、提案している構文がGoではうまく機能しないことを指摘しているだけです。 おそらくもっと何か

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

これは、型パラメーターのスコープとこれを解析する方法に関して、さらにいくつかの質問を示しています。

@aarondlあなたの提案について私が持っている質問も他にもあります。 たとえば、制約を許可しないため、制約のないポリモーフィズムのみが取得されます。 取得した値に対して何も実行できないため、一般的にはそれほど便利ではありません（たとえば、すべてのタイプが有効なマップキーであるとは限らないため、マップを使用してコレクションを実装できませんでした）。 誰かがそのようなことをしようとするとどうなりますか？ コンパイル時のエラーの場合、インスタンス化（先のC ++エラーメッセージ）または定義（すべてのタイプで機能するものがないため、基本的に何もできません）について文句を言いますか？

@keeanそれでも、 aがリスト（またはスライスやその他のコレクション）に制限されている方法を理解できません。 これは、コレクションのコンテキスト依存の特別な文法ですか？ もしそうなら、その価値は何ですか？ この方法でユーザー定義型を宣言することはできません。

@Meroviusこれは、Goが多重ディスパッチを実行できず、「関数」の最初の引数を特別なものにすることを意味しますか？ これは、関連付けられたタイプが複数パラメーターのインターフェースよりも適していることを示唆しています。 このようなもの：

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt(c Collection, e Collection.Element) {...}

ただし、2つのコレクションが同じタイプになるように制約するものがないため、これにはまだ問題があります...次のようなものが必要になります。

func[A] useIt(c A, e A.Element) requires A:Collection

違いを説明するために、マルチパラメータインターフェイスにはインスタンス選択に参加する追加の_input_タイプがあります（したがって、マルチディスパッチとの接続）が、関連するタイプは_output_タイプであり、レシーバータイプのみがインスタンス選択に参加します。関連するタイプは、受信者のタイプによって異なります。

@ dc0d aとbは、Haskell型クラスと同様に、インターフェースの型パラメーターです。 Collectionと見なされるものについては、インターフェイスのタイプに一致するメソッドを定義する必要があります。ここで、 aとbは任意のタイプにすることができます。 ただし、 @ Meroviusが指摘しているように、Goインターフェースはメソッドベースであり、多重ディスパッチをサポートしていないため、マルチパラメーターインターフェースは適切ではない可能性があります。 Goのシングルディスパッチメソッドモデルでは、複数のパラメーターの代わりに、インターフェイスに関連付けられたタイプを使用する方が適しているように思われます。 ただし、多重ディスパッチがないため、 unify(x, y)のような関数を実装するのは難しく、ダブルディスパッチパターンを使用する必要があります。これはあまり良くありません。

マルチパラメータについてもう少し詳しく説明すると、次のようになります。

type Cloneable[A] interface {
   clone(x A) A
}

ここでaは任意のタイプを表します。正しい関数が定義されている限り、それがCloneableであると見なす限り、それが何であるかは関係ありません。 インターフェイスは、型自体ではなく、型に対する制約と見なされます。

func clone(x int) int {...}

したがって、「clone」の場合、インターフェイス定義のintをaに置き換え、置換が成功した場合はcloneを呼び出すことができます。 これは、次の表記法とうまく一致します。

func[A] test(x A) A requires Cloneable[A] {...}

これは次と同等です。

type Cloneable interface {
   clone() Cloneable
}

ただし、メソッドではなく関数を宣言し、複数のパラメーターで拡張できます。 多重ディスパッチのある言語を使用している場合、関数/メソッドの最初の引数について特別なことは何もないので、別の場所に書き込むのはなぜですか。

Goには複数のディスパッチがないため、これはすべて一度に変更するには多すぎるように感じ始めます。 制限はありますが、関連付けられたタイプの方が適しているようです。 これにより、抽象的なコレクションは可能になりますが、統合などの洗練されたソリューションは可能になりません。

@Merovius提案をご覧いただきありがとうございます。 私はあなたの懸念に対処しようとします。 私たちがそれについてもっと議論する前にあなたが提案を親指で下ろしたのは悲しいです、私はあなたの考えを変えることができることを願っています-または多分あなたは私のものを変えることができます:)

無制限の先読み：
したがって、提案で述べたように、現在、Go文法には、ほとんどすべての「終わり」を構文的に検出するための優れた方法があるようです。 そして、暗黙の一般的な引数のために、私たちはまだそうします。 一文字の小文字は、そのジェネリック引数を作成する構文構造です-または、そのインライントークンを作成することにしたものは何でも、構文が十分に気に入った場合は、提案の@aのようなトークン化されたものにフォールバックすることもできますが、そうではありませんトークンがないとコンパイラの難しさを考えると可能ですが、それを行うとすぐに提案は多くの魅力を失います。

aはジェネリック型の引数であることがわかっているため、この提案でのtype LinkedList aの問題はそれほど難しくありません。したがって、これはtype LinkedListと同じコンパイラエラーで失敗します。 prog.go:3:16: expected type, found newline (and 1 more errors)で失敗します。 元の投稿は実際には出てこなかったのですが、具体的なタイプ[a-z]{1}という名前を付けることはできなくなりました。これは、この問題を解決し、私たち全員が大丈夫だと思う犠牲です。作成中（今日のGoコードで1文字の名前を持つ実際の型を作成する場合にのみ不利益が見られます）。

制約のないポリモーフィズムです
あらゆる種類の特性やジェネリック引数の制約を省略した理由は、それがGoでのインターフェイスの役割であると感じているためです。値を使用して何かを実行する場合、その値は完全にジェネリック型ではなくインターフェイス型である必要があります。 この提案はインターフェースでもうまくいくと思います。

この提案では、 +のような演算子を使用した場合と同じ問題が発生するため、すべての数値型に対して汎用のadd関数を作成することはできませんが、引数として汎用のadd関数を受け入れることはできます。 次のことを考慮してください。

func Sort(slice []a, compare func (a, a) bool) { ... }

スコーピングに関する質問

ここに例を示しました：

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

原則として、これらの識別子の範囲は、それらが含まれる特定の宣言/定義にバインドされています。それらはどこにも共有されておらず、その理由はわかりません。

@keeanこれは非常に興味深いことですが、他の人が指摘しているように、実際にインターフェイスを実装できるようにするには、そこに表示されているものを変更する必要があります（現在、この例では、レシーバーを備えたメソッドはなく、関数のみです）。 これが私の最初の提案にどのように影響するかについてもっと考えようとしています。

その一般的な引数を作成する構文構造である1文字の小文字

私はそれについて気分が悪い。 それは、識別子が文脈に依存しているもののために別々のプロダクションを持つことを必要とし、またタイプのために特定の識別子を恣意的に禁止することを意味します。 しかし、これらの詳細について話すときではありません。

この提案では、+のような演算子を使用した場合と同じ問題が発生します。

私はこの文を理解していません。 現在、+演算子にはこれらの問題はありません。これは、そのオペランドのタイプがローカルで既知であり、エラーメッセージが明確で明確であり、問​​題の原因を示しているためです。 すべての可能なタイプで許可されていないジェネリック値の使用を禁止したいと言っていると仮定して正しいですか（そのような操作の多くは考えられません）？ そして、ジェネリック関数で問題のある式のコンパイラエラーを作成しますか？ ジェネリック医薬品の価値を制限しすぎるIMO。

値を使用して何かを実行したい場合、その値は完全にジェネリック型ではなく、インターフェース型である必要があります。

ジェネリックが必要な2つの主な理由は、パフォーマンス（インターフェイスの折り返しを避ける）と型の安全性（同じ型がどちらであるかを気にせずに、異なる場所で使用されるようにすること）です。 これはそれらの理由を無視しているようです。

一般的なadd関数を引数として受け入れることができます。

本当です。 しかし、かなり非人間的です。 sort APIについて、そこにどれだけの苦情があるかを考えてみてください。 多くの汎用コンテナーの場合、呼び出し元が実装して渡す必要のある関数の量は法外なようです。 container/heapの実装は、この提案の下でどのように見え、人間工学の観点から、現在の実装よりもどのように優れているかを考えてみてください。 せいぜい、ここでの勝利はごくわずかであるように思われます。 より多くの些細な機能を実装する必要があります（そして、各使用サイトで複製/参照）。

@メロヴィクス

@aarondlからこの点について考える

一般的なadd関数を引数として受け入れることができます。

中置演算子を定義するための構文を考えると、加算のオーバーロードを可能にするAddableインターフェイスがある方がよいでしょう。

type Addable interface {
   + (x Addable, y Addable) Addable
}

残念ながら、これは機能しません。これは、すべてのタイプが同じであると期待していることを表していないためです。 追加可能オブジェクトを定義するには、マルチパラメータインターフェイスのようなものが必要になります。

type Addable[A] interface {
   + (x A, y A) A
}

次に、Goで多重ディスパッチを実行する必要があります。これは、関数内のすべての引数がインターフェイスマッチングのレシーバーのように扱われることを意味します。 したがって、上記の例では、インターフェイス定義の関数定義を満たす関数+が定義されている場合、どのタイプもAddableになります。

しかし、これらの変更を考えると、次のように書くことができます。

type S struct {
   value: int
}

func (+) (x S, y S) S {
   return S {
      value: x.value + y.value
   }
}

func main() {
    println(S {value: 27} + S {value: 5})
}

もちろん、関数のオーバーロードと多重ディスパッチは、人々がGoで決して望んでいないことかもしれませんが、ベクトル、行列、複素数などのユーザー定義型で基本的な算術を定義するようなことは常に不可能です。 上で述べたように、インターフェースの「関連付けられた型」は、ジェネリックプログラミング機能のいくらかの増加を可能にしますが、完全な一般性ではありません。 多重ディスパッチ（およびおそらく関数のオーバーロード）は、Goで発生する可能性のあるものですか？

ベクトル、行列、複素数などのユーザー定義型で基本的な算術を定義するようなことは、常に不可能です。

一部の人は、機能を検討するかもしれません:) AFAIRどこかに浮かんでいる提案やスレッドがあり、それが必要かどうかを議論しています。 FWIW、これは-再び-話題から外れてさまよっていると思います。 演算子のオーバーロード（または一般的な「Gomore Haskell」のアイデア）は、実際にはこの問題のポイントではありません:)

多重ディスパッチ（およびおそらく関数のオーバーロード）は、Goで発生する可能性のあるものですか？

絶対とは絶対言うな。 個人的には期待していません。

@メロヴィクス

一部の人はその機能を考えるかもしれません:)

もちろん、Goがそれを行わない場合は、他の言語があります:-) Goがすべての人にとってすべてである必要はありません。 Goでジェネリックスのスコープを確立しようとしていました。 私は自分自身と定型文を繰り返すことに嫌悪感を持っているので、完全に一般的な言語を作成することに焦点を当てています（そして私はマクロが好きではありません）。 毎回ペニーを持っていた場合、特定のデータ型のリンクリストまたはツリーを「C」で作成する必要がありました。 それを理解するために頭の中に保持し、変更を通じて維持する必要のあるコードの量のために、実際には小さなチームにとっていくつかのプロジェクトを不可能にします。 ジェネリックスを必要としない人は、まだ十分な大きさのプログラムを作成していないと思うことがあります。 もちろん、代わりに、開発者の大規模なチームが何かに取り組んでいて、各開発者がコード全体のごく一部にのみ責任を持つようにすることもできますが、私は1人の開発者（または小さなチーム）をできるだけ効果的にすることに興味があります。

関数のオーバーロードと多重ディスパッチが範囲外であり、 @ aarondlの提案による解析の問題も考慮すると、関連する型をインターフェイスに追加し、型パラメーターを関数に追加することは、ほぼ必要な範囲であるように思われます。 Goでジェネリックを使用します。

このようなものは正しい種類のもののように思われます：

type Collection interface {
   type Element
   Member(e Element) Bool
   Insert(e Element) Collection
}

type IntSlice struct {
    value []Int,
}

type IntSlice.Element = Int

func (IntSlice) Member(e Int) Bool {...}
func (IntSlice) Insert(e Int) IntSlice {...}

func useIt<T>(c T, e T.Element) requires T:Collection {...}

次に、実装において、パラメトリック型を使用するか、全称記号型を使用するかを決定します。 パラメトリック型（Javaなど）の場合、「ジェネリック」関数は実際には関数ではなく、ある種のタイプセーフな関数テンプレートであるため、型パラメーターが指定されていない限り、引数として渡すことはできません。

f(useIt) // not okay with parametric types
f(useIt<List>) // okay with parametric types

全称記号型を使用すると、useItを引数として渡すことができ、 f内に型パラメーターを指定できます。 パラメトリック型を好む理由は、コンパイル時にポリモーフィズムを単形化できるため、実行時にポリモーフィック関数を作成する必要がないためです。 Goはすでにインターフェースでランタイムディスパッチを実行しているため、これがGoの懸念事項かどうかはわかりません。 useItのtypeパラメーターがCollectionを実装している限り、実行時に正しいレシーバーにディスパッチできます。定量化はおそらくGoにとって正しい方法です。

SFINAEは@bcmillsによってのみ言及されているのだろうか。 提案では言及されていません（ただし、ソートは例としてあります）。
スライスとリンクリストのSortどのように見えるでしょうか？

@keean
あなたの提案で一般的な「スライス」コレクションをどのように定義するのか理解できません。 'Collection'を実装している可能性のある 'IntSlice'を定義しているようですが（Insertはインターフェイスで必要なタイプとは異なるタイプを返します）、これは一般的な 'slice'ではありません。 、およびメソッドの実装はint専用です。 タイプごとに特定の実装を定義する必要がありますか？

ジェネリックスを必要としない人は、まだ十分な大きさのプログラムを作成していないと思うことがあります。

私はあなたに印象が間違っていることを保証することができます。 そして、FWIW、ISTMは、「反対側」が「必要性を認識していない」ことを「使用を認識していない」ことと同じバケットに入れていることを示しています。 私はその使用法を見て、それを論駁しません。 でも、その必要性はあまりわかりません。 大規模なコードベースでも、問題なく実行できます。

また、「正しく行われることを望み、既存の提案がどこにないのかを指摘する」ことと、「アイデアそのものに根本的に反対する」ことも間違えないでください。

また、 @ aarondlの提案による構文解析の問題も考えられます。

私が言ったように、私は構文解析の問題について話すことは今のところ本当に生産的だとは思いません。 構文解析の問題は解決できます。 制約されたポリモーフィズムのラックは、意味的にはるかに深刻です。 IMO、それなしでジェネリックを追加することは、本当に努力する価値がありません。

@urandom

あなたの提案で一般的な「スライス」コレクションをどのように定義するのか理解できません。

上記のように、スライスのタイプごとに個別の実装を定義する必要がありますが、汎用インターフェイスの観点からアルゴリズムを記述できることで利益を得ることができます。 すべてのスライスにジェネリック実装を許可する場合は、パラメトリック関連のタイプとメソッドを許可する必要があります。 レシーバータイプの前に発生するように、タイプパラメーターをキーワードの後に​​移動したことに注意してください。

type<T> []T.Element = Int

func<T> ([]T) Member(e T) Bool {...}
func<T> ([]T) Insert(e T) Collection {...}

ただし、特殊化に対処する必要があります。これは、誰かがより特殊化された[]intに関連付けられたタイプとメソッドを定義でき、どちらを使用するかを処理する必要があるためです。 通常は、より具体的なインスタンスを使用しますが、さらに複雑なレイヤーが追加されます。

これが実際にどれだけあなたを得るのかはわかりません。 上記の私の元の例では、インターフェイスを使用して一般的なコレクションに作用する一般的なアルゴリズムを記述でき、実際に使用するタイプのメソッドと関連するタイプを提供するだけで済みます。 私にとっての主な利点は、任意のコレクションでの並べ替えなどのアルゴリズムを定義し、それらのアルゴリズムをライブラリに配置できることです。 次に「図形」のリストがある場合は、図形のリストのコレクションインターフェイスメソッドを定義するだけで、ライブラリ内の任意のアルゴリズムを使用できます。 すべてのスライスタイプのインターフェイスメソッドを定義できることは、私にはあまり興味がなく、Goにとっては複雑すぎるかもしれません。

@メロヴィクス

でも、その必要性はあまりわかりません。 大規模なコードベースでも、問題なく実行できます。

100,000行のプログラムに対応できる場合は、100,000行の非ジェネリック行よりも100,000行の一般行でより多くのことを実行できます（繰り返しのため）。 したがって、あなたは非常に大きなコードベースに対処できるスーパースターの開発者かもしれませんが、冗長性を排除するので、非常に大きな汎用コードベースでより多くのことを達成できます。 そのジェネリックプログラムは、さらに大きな非ジェネリックプログラムに拡張されます。 あなたはまだ複雑さの限界に達していないように私には思えます。

しかし、あなたは正しいと思います。「必要性」は強すぎます。ジェネリックスがないことに不満を感じることもありますが、私は喜んでgoコードを書いています。これを回避するには、コードを追加するだけです。Goでは、そのコードは完全に直接的なものです。と文字通り。

制約されたポリモーフィズムの欠如は、意味的にはるかに深刻です。 IMO、それなしでジェネリックを追加することは、本当に努力する価値がありません。

私はこれに賛同する。

100,000の非ジェネリックラインよりも100,000のジェネリックラインでより多くのことができるようになります（繰り返しのため）

あなたの仮説の例から、これらの行の何％が総称関数になるのか興味がありますか？
私の経験では、これは（115k LOCのコードベースから）2％未満であるため、「コレクション」用のライブラリを作成しない限り、これは適切な議論ではないと思います。

最終的にジェネリック医薬品を入手したいのですが

@keean

Haskellではこの例を実行できないというあなたの主張に関して、コードは次のとおりです。

このコードは、私が書いたコードと道徳的に同等ではありません。 ICloneableインターフェイスに加えて、新しいCloneableラッパータイプが導入されています。 Goコードにはラッパーは必要ありませんでした。 サブタイピングをサポートする他の言語も同様です。

@andrewcmyers

このコードは、私が書いたコードと道徳的に同等ではありません。 ICloneableインターフェイスに加えて、新しいCloneableラッパータイプが導入されています。

これはこのコードが行うことではありません：

type Cloneable interface {...}

これは、インターフェースから派生したデータ型「Cloneable」を導き出します。 インターフェイスのインスタンス宣言がないため、「ICloneable」は表示されません。メソッドを宣言するだけです。

インターフェイスを実装するタイプが構造的に互換性がある必要がない場合、サブタイピングと見なすことができますか？

@keean Cloneableは単なる型であり、実際には「データ型」ではないと思います。 Javaのような言語では、コードとは異なり、ラッパーがないため、 Cloneableの抽象化に追加のコストは基本的にありません。

インターフェイスを実装するタイプ間の構造的な類似性を要求することは制限的で望ましくないように思われるので、ここであなたが何を考えているかについて混乱しています。

@andrewcmyers
タイプとデータタイプを同じ意味で使用しています。 データを含むことができるすべての型はデータ型です。

コードとは異なり、ラッパーがないためです。

Goタイプは常にボックス化されているため、ラッパーは常に存在します。したがって、ラッパーはすべての周りに存在します。 Haskellはボックス化されていないタイプを持っているので、ラッパーを明示的にする必要があります。

インターフェイスを実装するタイプ間の構造的な類似性のため、ここで何を考えているのか混乱しています。

構造サブタイピングでは、タイプが「構造的に互換性がある」必要があります。 継承を伴うオブジェクト指向言語のような明示的な型階層がないため、サブタイピングは名目上できないため、存在する場合は構造的である必要があります。

しかし、私はあなたが何を意味するのかわかります。これは、インターフェイスを、必要なメソッドを実装する任意のタイプとのある種の暗黙の名目サブタイプ関係を持つ、インターフェイスではなく抽象基本クラスであると見なすと説明します。

Goは現在両方のモデルに適合していると思います。ここからどちらの方向にも進む可能性がありますが、クラスではなくインターフェイスと呼ぶことは、サブタイピングを行わない考え方を示唆していると思います。

@keeanあなたのコメントがわかりません。 最初にあなたはあなたが同意しないと私に言い、そして私は「まだ私の複雑さの限界に達していない」とあなたは私にあなたが同意すると言います（その「必要性」はあまりにも強い言葉です）。 また、あなたの議論は誤りだと思います（LOCが複雑さの主要な尺度であり、コードのすべての行が等しいと仮定します）。 しかし、何よりも、「より複雑なプログラムを書いているのは誰か」というのは、実際には生産的な議論ではないと思います。 私は、「あなたが私に同意しない場合、それはあなたが難しい問題や興味深い問題に取り組んでいないことを意味しているに違いない」という議論は説得力がなく、誠意を持って外れないことを明確にしようとしていました。 同等の能力を持ち、同じように興味深いことをしながら、この機能の重要性について人々があなたに反対できることを信頼していただければ幸いです。

@merovius
私はあなたが私よりも有能なプログラマーである可能性が高いと言っていたので、より複雑に作業することができます。 確かに、あなたがそれほど面白くなく、それほど複雑でない問題に取り組んでいるとは思いません。そのように遭遇したことを残念に思います。 私は昨日スキャナーを動作させるために費やしましたが、これは非常に興味深い問題ではありませんでした。

ジェネリックは、限られた頭脳でより複雑なプログラムを書くのに役立つと思います。また、ジェネリックを「必要としない」ことも認めています。 それは程度の問題です。 ジェネリックスがなくてもプログラミングはできますが、必ずしも同じ複雑さのソフトウェアを作成できるとは限りません。

私が誠意を持って行動していることを安心させてくれることを願っています。ここに隠された議題はありません。Goがジェネリックを採用しない場合でも、それを使用します。 私はジェネリックスを行うための最良の方法について意見を持っていますが、それだけではありません。私は自分の経験からしか話すことができません。 私が助けていないのなら、私が時間を費やすことができる他のことがたくさんあるので、言葉を言うだけで、私は他の場所に再び焦点を合わせます。

@Meroviusダイアログを続けてくれてありがとう。

| ジェネリックが必要な2つの主な理由は、パフォーマンス（インターフェイスの折り返しを避ける）と型の安全性（同じ型がどちらであるかを気にせずに、異なる場所で使用されるようにすること）です。 これはそれらの理由を無視しているようです。

たぶん、私が提案したものを非常に異なって見ているのかもしれません。私の観点からは、私が知る限り、これらの両方を行っているのでしょうか。 リンクリストの例では、インターフェイスによるラッピングがないため、特定のタイプに対して手書きされた場合と同じようにパフォーマンスが向上するはずです。 型安全性の面でも同じです。 あなたがどこから来ているのかを理解するのに役立つ反例はありますか？

| 本当です。 しかし、かなり非人間的です。 ソートAPIについてどこにどれだけの苦情があるかを考えてください。 多くの汎用コンテナーの場合、呼び出し元が実装して渡す必要のある関数の量は法外なようです。 人間工学の観点から、コンテナ/ヒープの実装はこの提案の下でどのように見え、現在の実装よりもどのように優れているかを考えてみてください。 せいぜい、ここでの勝利はごくわずかであるように思われます。 より多くの些細な機能を実装する必要があります（そして、各使用サイトで複製/参照）。

私は実際にはこれにはまったく関心がありません。 関数の数が法外なものになるとは思いませんが、いくつかの反例を目にすることは間違いありません。 人々が不満を言ったAPIは、関数を提供する必要のあるAPIではなく、ここにある元のAPIであったことを思い出してください： https ：//golang.org/pkg/sort/#Interfaceここで、単純な新しいタイプを作成する必要がありましたスライス+タイプを入力し、3つのメソッドを実装します。 このインターフェースに関連する苦情と苦痛に照らして、以下が作成されました： https ：//golang.org/pkg/sort/#Slice、私はこのAPIに問題はなく、このパフォーマンスのペナルティを回復します提案では、定義をfunc Slice(slice []a, less func(a, a) bool)に変更するだけで議論しています。

container/heapのデータ構造に関しては、どのような一般的な提案を受け入れても、全体を書き直す必要があります。 $＃ sortパッケージが独自のデータ構造の上にアルゴリズムを提供しているのと同じようにcontainer/heap []interface{}が、どちらのパッケージもデータ構造を所有していません。それに関連するコスト。 ジェネリックスのおかげで具体的なタイプのスライスを所有するHeapを持つことができるので、おそらくそれらを変更します。これは、私がここで見たどの提案にも当てはまります（私自身を含む） 。

私が提案したものについての私たちの見方の違いをばらばらにしようとしています。 そして、（構文的に個人的な好みを超えて）不一致の根本は、ジェネリック型に制約がないことだと思います。 しかし、私はまだそれが私たちに何をもたらすのかを理解しようとしています。 答えが、パフォーマンスに関係するものがインターフェイスを使用することを許可されていないということである場合、ここで言えることはあまりありません。

次のハッシュテーブル定義を検討してください。

// Hasher turns a key into a hash
type Hasher interface {
  func Hash() []byte
}

type HashTable v struct {
   Keys   []Hasher
   Values []v
}

// Note that the generic arguments must be repeated here and immediately
// understood without reading another line of code, which to me
// is a readability win over the sudden appearance of the K and V which are
// defined elsewhere in the code in the example below. This is of course because
// the tokenized type declarations with constraints are fairly painful in general
// and repeating them everywhere is simply too much.
func (h (*HashTable v)) Insert(key Hasher, value v) { ... }

[]Hasherはパフォーマンス/ストレージの問題のために初心者ではなく、Goでジェネリックスの実装を成功させるには、絶対に次のようなものが必要だと言っていますか？

// Without selecting another proposal I have no idea how the constraint might be defined or implemented so let's just pretend
type [K: Hasher, V] HashTable a struct {
   Keys   []K
   Values []V
}

func (h *HashTable) Insert(key K, value V) { ... }

うまくいけば、あなたは私がどこから来ているのかわかるでしょう。 しかし、特定のコードに課したい制約を私が理解していない可能性は間違いありません。 要件が何であるか、そして提案がどのようにそれらを失敗させているかをより完全に理解したいと思っているにもかかわらず、私が考慮していないユースケースがあるかもしれません。

たぶん、私が提案したものを非常に異なって見ているのかもしれません。私の観点からは、私が知る限り、これらの両方を行っているのでしょうか。

引用しているセクションの「これ」は、インターフェースの使用を指します。 問題は、プロポーザルがどちらも実行しないということではなく、プロポーザルが制約付きポリモーフィズムを許可していないことです。これにより、ほとんどの使用法が除外されます。 そして、あなたが提案した代替案は、ジェネリックスのコアユースケースにも実際には対応していないインターフェイスです（私が言及した2つの理由のため）。

たとえば、（最初に作成された）提案では、実際には、あらゆる種類の汎用マップを作成することはできませんでした。これは、少なくとも==を使用してキーを比較できる必要があるためです（これは制約であるため、マップには制約付きポリモーフィズムが必要です）。

このインターフェースに関連する苦情と苦痛に照らして、以下が作成されました： https ：//golang.org/pkg/sort/#Slice

このインターフェイスは、長さとスワッピングのリフレクションに依存しているため、ジェネリックスの提案ではまだ使用できないことに注意してください（したがって、スライス操作に制約があります）。 そのAPIをジェネリックスが達成できるはずの下限として受け入れたとしても（多くの人はそうしません。そのAPIの型安全性の欠如についてはまだ多くの不満があります）、あなたの提案は合格しません。そのバー。

ただし、ここでも、作成した特定のポイントに対する応答を引用しています。つまり、APIで関数リテラルを渡すことで、制約されたポリモーフィズムを取得できます。 そして、制約されたポリモーフィズムの欠如を回避するために提案したその特定の方法では、多かれ少なかれ古いAPIを実装する必要があります。 つまり、この議論に対する私の回答を引用しているのですが、それを繰り返しているだけです。

定義をfuncSlice（slice [] a、less func（a、a）bool）に変更するだけで、議論している提案の下でこれのパフォーマンスペナルティを回復します。

ただし、これは古いAPIです。 「私の提案では制約付きポリモーフィズムは許可されていませんが、ジェネリックを使用できず、代わりに既存のソリューション（リフレクション/インターフェイス）を使用できるため、問題ありません」とおっしゃっています。 ええと、「あなたの提案は、人々がジェネリックを望んでいる最も基本的なユースケースを許可していません」と「私たちは、それらの最も基本的なユースケースのためにジェネリックなしで人々がすでに行っていることをすることができます」と答えることは私たちを得るようには見えませんどこでも、TBH。 基本的なコンテナタイプ、並べ替え、最大値でさえ書くのに役立たないジェネリックスの提案は、それだけの価値がないようです。

これは、私がここで見た提案（私自身を含む）のいずれにも当てはまります。

ほとんどのジェネリックスの提案には、型パラメーターを制約する方法が含まれています。 つまり、「タイプパラメータにはLessメソッドが必要」、または「タイプパラメータは比較可能でなければならない」と表現します。 あなたの-AFAICT-はそうではありません。

次のハッシュテーブル定義を検討してください。

あなたの定義は不完全です。 a）キータイプにも同等性が必要であり、b）異なるキータイプの使用を妨げていない。 つまり、これは合法です。

type hasherA uint64

func (a hasherA) Hash() []byte {
    b := make([]byte, 8)
    binary.BigEndian.PutUint64(b, uint64(a))
    return b
}

type hasherB string

func (b hasherB) Hash() []byte {
    return []byte(b)
}

h := new(HashTable int)
h.Insert(hasherA(42), 1)
h.Insert(hasherB("Hello world"), 2)

ただし、さまざまなキータイプを使用しているため、合法ではありません。 つまり、コンテナは人々が望む程度にタイプチェックされていません。 キータイプと値タイプの両方でハッシュテーブルをパラメーター化する必要があります

type HashTable k v struct {
    Keys []k
    Values []v
}

func (h *(HashTable k v)) Insert(key k, value v) {
    // You can't actually do anything with k, as it's unconstrained. i.e. you can't hash it, compare it…
    // Implementing this is impossible in your proposal.
}

// If it weren't impossible, you'd get this:
h := new(HashTable hasherA int)
h[hasherA(42)] = 1
h[hasherB("Hello world")] = 2 // compile error - can't use hasherB as hasherA

または、それが役立つ場合は、ハッシュセットを実装しようとしていると想像してください。 同じ問題が発生しますが、結果のコンテナには、 interface{}を超える追加の型チェックがありません。

これが、提案が最も基本的なユースケースに対応していない理由です。ポリモーフィズムを制約するためにインターフェースに依存していますが、実際にはそれらのインターフェースの整合性をチェックする方法を提供していません。 一貫性のある型チェックを行うことも、ポリモーフィズムを制約することもできますが、両方を行うことはできません。 しかし、両方が必要です。

Goでジェネリックスの実装を成功させるには、絶対に次のようなものが必要ですか？

それは少なくとも私がそれについてどう感じているか、ええ、ほとんどです。 提案がタイプセーフなコンテナの作成やソートを許可しない場合、または…既存の言語にコストを正当化するのに十分重要なものを実際に追加することはありません。

@メロヴィクスわかりました。 私はあなたが何を望んでいるのか理解していると思います。 あなたのユースケースは私が望むものから非常に遠いことを覚えておいてください。 あなたが言ったように、それは少数意見かもしれないと私は思うが、私はタイプセーフな容器を本当にかゆくはしていない。 私が見たい最大のことのいくつかは、エラーではなく結果タイプであり、どこでも重複や反映のない簡単なスライス操作であり、私の提案は適切な対処方法を実行します。 ただし、基本的なユースケースがインターフェイスを使用せずに汎用コンテナを作成している場合、どのように「最も基本的なユースケースに対応していない」かがわかります。

このインターフェイスは、長さとスワッピングのリフレクションに依存しているため、ジェネリックスの提案ではまだ使用できないことに注意してください（したがって、スライス操作に制約があります）。 そのAPIをジェネリックスが達成できるはずの下限として受け入れたとしても（多くの人はそうしません。そのAPIの型安全性の欠如についてはまだ多くの不満があります）、あなたの提案は合格しません。そのバー。

これを読むと、この提案の下で一般的なスライスがどのように機能するか/すべきかを完全に誤解していることは明らかです。 この誤解によって、「このインターフェースはまだあなたの提案では不可能である」という誤った結論に達したのです。 どんな提案の下でも、一般的なスライスが可能でなければなりません、これは私が思うことです。 そして、私が見た世界のlen()は、次のように定義されます。 func len(slice []a)これは、任意のスライスに対して非反射的な方法で長さをカウントできることを意味する一般的なスライス引数です。 これが先ほど申し上げたように（スライス操作が簡単）この提案のポイントの多くであり、私が与えた例と私が作った要点を通してそれをうまく伝えることができなかったのは残念です。 一般的なスライスは、今日の[]intと同じくらい簡単に使用できるはずです。これに対応していない提案（スライス/配列の交換、割り当て、len、capなど）については、もう一度言います。 ）私の意見では不十分です。

そうは言っても、今ではお互いの目標が何であるかがはっきりとわかりました。 私がやったことを提案したとき、それは単に構文上の提案であり、詳細は非常に曖昧であると非常に言いました。 しかし、とにかく詳細に取り掛かったのですが、それらの詳細の1つは制約がないことでした。私がそれを書いたとき、私がやりたいことにとって重要ではないので、それらを念頭に置いていませんでした。 、それらを追加できなかった、またはそれらが望ましくないということではありません。 提案された構文を続行し、制約をシューホーンしようとする際の主な問題は、一般的な引数の定義が現在（意図的に）繰り返されているため、制約などを決定するために他の場所でコードを参照することがないことです。どうすればこれを維持できるかわかりません。

最良の反例は、前に説明したソート関数です。

type Sort(slice []a:Lesser, less func(a:Lesser, a:Lesser)) { ... }

ご覧のとおり、これを実現するための優れた方法はありません。ジェネリックスへのトークンスパムアプローチは、再び良く聞こえ始めます。 これらの制約を定義するには、元の提案から2つのことを変更する必要があります。

• 型引数をポイントして制約を与える方法が必要です。
• 制約は単一の定義よりも長く続く必要があります。おそらくそのスコープはタイプであり、おそらくそのスコープはファイルです（ファイルは実際にはかなり合理的に聞こえます）。

免責事項：以下は提案の実際の修正ではありません。ランダムな記号を投げているだけです。これらの構文を例として使用して、提案を元の状態に修正するために何ができるかを示しています。

// Decorator style, follows the definition of the type thorugh all
// of it's methods.
<strong i="14">@a</strong>: Lesser, Hasher, Equaler
func Sort(slice []a) { ... }
<strong i="15">@k</strong>: Equaler, Hasher
type HashTable k v struct

// Inline, follows the definition of the type through
// all of it's methods.
func [a: Hasher, Equaler] Sort(slice []a) { ... }
type [k: Hasher, Equaler] HashTable k v struct

// File-scope global style, if k appears as a generic argument
// it's constrained by this that appears at the top of the file underneath
// the imports but before any other code.
<strong i="16">@k</strong>: Equaler, Hasher

繰り返しになりますが、上記のどれも実際には提案に追加したくないことに注意してください。 問題を解決するためにどのような構成を使用できるかを示しているだけであり、それらがどのように見えるかは今のところやや無関係です。

次に答える必要のある質問は、暗黙の一般的な引数からまだ価値を得るのかということです。 提案の主なポイントは、言語のクリーンなGoのような感触を維持し、物事をシンプルに保ち、過剰なトークンを排除することによって物事を十分に低ノイズに保つことでした。 マップ関数や結果タイプの定義など、制約が不要な多くの場合、見栄えは良く、Goのように感じますか、便利ですか？ 制約が何らかの形で利用可能であると仮定します。

func map(slice []a, mapper func(a) b) {
  for i := range slice {
    slice[i] = mapper(slice[i])
  }
}

type Result a b struct {
  Ok  a
  Err b
}

@aarondl説明してみます。 型制約が必要な理由は、それが型の関数またはメソッドを呼び出すことができる唯一の方法だからです。 制約のない型a考えてみてください。これはどの型である可能性がありますか。文字列、Intなどの可能性があります。 したがって、タイプがわからないため、関数やメソッドを呼び出すことはできません。 型スイッチとランタイムリフレクションを使用して型を取得し、その上でいくつかの関数またはメソッドを呼び出すことができますが、これはジェネリックスでは避けたいものです。 たとえば、タイプを制約する場合、 aは動物であり、 aで動物に対して定義された任意のメソッドを呼び出すことができます。

あなたの例では、はい、マッパー関数を渡すことができますが、これにより、関数が多くの引数を取ることになり、基本的にはインターフェイスのない言語のようになり、ファーストクラスの関数だけになります。 タイプaで使用するすべての関数を渡すと、実際のプログラムで非常に長い関数のリストが取得されます。特に、依存性注入用のジェネリックコードを主に記述している場合は、次のようにします。結合を最小限に抑えます。

たとえば、mapを呼び出す関数も汎用である場合はどうなりますか？ ジェネリックなどを呼び出す関数の場合はどうなりますか。 aのタイプがまだわからない場合、マッパーをどのように定義しますか？

func m(slice []a) []b {
   mapper := func(x a) b {...}
   return map(slice, mapper)
}

mapperを定義しようとすると、 xでどの関数を呼び出すことができますか？

@keean制約の目的と機能を理解しています。 私は単に、ジェネリックコンテナ構造体（いわばジェネリックコンテナではない）やジェネリックスライスのような単純なものほど高く評価していないため、元の提案にそれらを含めていませんでした。

私は今でも、依存性注入を行っている場所のような問題に対する正しい答えはインターフェースであると信じています。それは単にジェネリックスにとって正しい場所ではないようですが、私が言うには誰ですか。 彼らの責任の重複は私の目には非常に大きいので、なぜ@Meroviusと私は、彼らなしで生きられるかどうかについて話し合う必要がありました。彼は、いくつかのユースケースで役立つと私に確信させてくれました。私が最初に行った提案に機能を追加するために私たちができるかもしれないことを少し調べました。

あなたの例として、xで関数を呼び出すことはできません。 ただし、それ自体で非常に役立つ他のスライスと同じように、スライスを操作することもできます。 また、func内のfuncが何であるかわからない...多分あなたはvarに割り当てるつもりでしたか？

@aarondl
おかげさまで構文を修正しましたが、意味はまだはっきりしていると思います。

上記の例では、パラメトリックポリモーフィズムとインターフェイスの両方を使用して、ある程度のジェネリックプログラミングを実現しましたが、多重ディスパッチがないため、達成可能な一般性のレベルに常に上限があります。 そのため、Goは私が探している機能を言語で提供しないようです。つまり、一部のタスクにGoを使用できないわけではありません。実際、私はすでに使用しており、使用したことがある場合でも正常に機能します。実際には1つの定義しか必要としないコードをカットアンドペーストします。 将来、そのコードを変更する必要がある場合、開発者が貼り付けられたすべてのインスタンスを見つけることができることを願っています。

それから私は、言語にそのような大きな変更を加えることなく可能な限られた一般性が、それが追加する複雑さを考慮して、良い考えであるかどうかについて、2つの考えを持っています。 たぶん、Goの方がシンプルなままで、前処理のようなマクロや、Goにコンパイルされる他の言語を追加して、これらの機能を提供できますか？ 一方、パラメトリック多型を追加することは、良い最初のステップです。 これらのタイプパラメータを制約できるようにすることは、次の良いステップです。 次に、関連付けられた型パラメーターをインターフェースに追加すると、かなり一般的なものになりますが、それはおそらく、多重ディスパッチなしで取得できる範囲です。 別々の小さな機能に分割することで、それらが受け入れられる可能性が高くなると思いますか？

@keean
多重ディスパッチは必要ですか？ ネイティブにサポートしている言語はほとんどありません。 C ++でさえそれをサポートしていません。 C＃はdynamicを介してそれをサポートしていますが、実際に使用したことはなく、一般的なキーワードは実際のコードでは非常にまれです。 私が覚えている例は、ジェネリックスを書くのではなく、JSON解析のようなものを扱っています。

多重ディスパッチは必要ですか？

私見、 @ keeanは、型クラス/インターフェースによって提供される静的多重ディスパッチについて話していると思います。
これは、メソッドのオーバーロードによってC ++でも提供されます（C＃についてはわかりません）

つまり、動的な多重ディスパッチは、共用体型のない静的言語では非常に面倒です。 動的言語は、静的型チェック（動的言語の部分的な型推論、C＃の「動的」型の場合と同じ）を省略することで、この問題を回避します。

タイプを「単なる」パラメータとして提供できますか？

func Append(t, t2 type, arr []t, value t2) []t {
    v := t(value) // conversion
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

@Inuartは書いた：

タイプを「単なる」パラメータとして提供できますか？

これがどの程度可能であるか、または外出先で望まれるかについては疑わしい

一般的な制約がサポートされている場合は、代わりに必要なことを実現できます。

func Append(arr []t, value s) []t  requires Convertible<s,t>{
    v := t(value) // conversion
    return append(arr, v)
}

var arr []int64
v := 0.5

arr = Append(arr, v)

また、これは制約付きでも可能であるはずです。

func convert(value s) t requires Convertible<s,t>{
    return t(value);
}

f:float64:=2.0

i:int64=convert(f)

その価値については、私たちのGenus言語は複数のディスパッチをサポートしています。 制約のモデルは、にディスパッチされる複数の実装を提供できます。

コンパイル時の安全性のためにConvertible<s,t>表記が必要であることを理解していますが、ランタイムチェックに低下する可能性があります

func Append(t, t2 type, arr []t, value t2) []t {
    v, ok := t(value) // conversion
    if !ok {
        panic(...) // or return an err
    }
    return append(arr, v)
}

var arr []float64
v := 0

arr = Append(float64, int, arr, v)

しかし、これはreflectのシンタックスシュガーのように見えます。

@Inuartのポイントは、コンパイラがコンパイル時に型が型クラスを実装していることを確認できるため、実行時の確認は不要です。 利点は、パフォーマンスの向上です（いわゆるゼロコストの抽象化）。 ランタイムチェックの場合は、 reflectを使用することもできます。

@creker

多重ディスパッチは必要ですか？

私はこれについてあまりにも気にしています。 一方では、（複数パラメーター型クラスを使用した）多重ディスパッチは、「Go」が「インターフェース値」と呼ぶ実存的存在ではうまく機能しません。

type Equals<T> interface {eq(right T) bool}
(left I) eq(right I) bool {return left == right}
(left I) eq(right F) bool {return false}
(left F) eq(right I) bool {return false}
(left F) eq(right F) bool {return left == right}

func main() {
    x := []Equals<?>{I{2}, F{4.0}, I{2}, F{4.0}}
}

Equalsのスライスを定義することはできません。これは、右側のパラメーターが同じコレクションからのものであることを示す方法がないためです。 Haskellではこれを行うことさえできません：

data Equals = forall a . IEquals a a => Equals a

タイプをそれ自体と比較することしかできないので、これは良くありません

data Equals = forall a b . IEquals a b => Equals a

bをaと同じコレクション内の別の存在になるように制約する方法がないため、これは適切ではありません（ aがコレクション内にある場合でも）。

ただし、新しいタイプでの拡張は非常に簡単です。

(left K) eq(right I) bool {return false}
(left K) eq(right F) bool {return false}
(left I) eq(right K) bool {return false}
(left F) eq(right K) bool {return false}
(left K) eq(right K) bool {return left == right}

そして、これはデフォルトのインスタンスまたは特殊化でさらに簡潔になります。

一方、これを「Go」で書き直すことができます。これは現在機能しています。

package main

type I struct {v int}
type F struct {v float32}

type EqualsInt interface {eqInt(left I) bool}
func (right I) eqInt (left I) bool {return left == right}
func (right F) eqInt (left I) bool {return false}

type EqualsFloat interface {eqFloat(left F) bool}
func (right I) eqFloat (left F) bool {return false}
func (right F) eqFloat (left F) bool {return left == right}

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

type EqualsLeft interface {eq(right EqualsRight) bool}
func (left I) eq (right EqualsRight) bool {return right.eqInt(left)}
func (left F) eq (right EqualsRight) bool {return right.eqFloat(left)}

type Equals interface {
    EqualsLeft
    EqualsRight
}

func main() {
    x := []Equals{I{2}, F{4.0}, I{2}, F{4.0}}
    println(x[0].eq(x[1]))
    println(x[1].eq(x[0]))
    println(x[0].eq(x[2]))
    println(x[1].eq(x[3]))
}

これは実存的（インターフェース値）でうまく機能しますが、はるかに複雑で、何が起こっているのか、どのように機能するのかを確認するのが難しく、タイプごとに1つのインターフェースが必要であり、許容可能なものをハードコーディングする必要があるという大きな制限がありますこのような右側のタイプ：

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

つまり、インターフェイスEqualsRightは拡張できないため、ライブラリソースを変更して新しいタイプを追加する必要があります。

したがって、マルチパラメータインターフェイスがないと、等式のような拡張可能な汎用演算子を定義できません。 マルチパラメータインターフェイスでは、存在（インターフェイス値）が問題になります。

提案された多くの構文（構文？） Blah[E]に関する私の主な問題は、基礎となる型にジェネリックスの包含に関する情報が表示されないことです。

例えば：

type Comparer[C] interface {
    Compare(other C) bool
}
// or
type Comparer c interface {
    Compare(other c) bool
}
...

これは、基になる型にさらに情報を追加する新しい型を宣言していることを意味します。 type宣言のポイントは、別のタイプに基づいて名前を定義することではありませんか？

私は次の行に沿って構文をもっと提案したいと思います

type Comparer interface[C] {
    Compare(other C) bool
}

つまり、実際にはComparerはinterface[C] { ... }に基づくタイプであり、 interface[C] { ... }はもちろんinterface { ... }とは別のタイプです。 これにより、必要に応じて、名前を付けずに汎用インターフェイスを使用できます（通常のインターフェイスで許可されています）。 このソリューションはもう少し直感的で、Goの型システムでうまく機能すると思いますが、間違っている場合は訂正してください。

注：ジェネリック型の宣言は、次の構文のインターフェイス、構造体、および関数でのみ許可されます。
interface[G] { ... }
struct[G] { ... }
func[G] (vars...) { ... }

次に、ジェネリックを「実装」すると、次の構文になります。
interface[G] { ... }[string]
struct[G] { ... }[string]
func[G] (vars...) { ... }[int](args...)

そして、もう少し明確にするためのいくつかの例を示します。

インターフェース

package add

type Adder interface[E] {
    // Adds the element and returns the size
    Add(elem E) int
}

// Adds the integer 5 to any implementation of Adder[int].
func AddFiveTo(a Adder[int]) int {
    return a.Add(5)
}

構造体

package heap

type List struct[T] {
    slice []T
}

func (l *List) Add(elem T) { // T is a type defined by the receiver
    l.slice = append(l.slice, elem)
}

機能

func[A] AddManyTo(a Adder[A], many ...A) {
    for _, each := range a {
        a.Add(each)
    }
}

これはGo2契約ドラフトに対応しており、その構文を使用しますが、パラメトリック多型の提案に適用されるため、ここに投稿します。

タイプパラメータの埋め込みは許可されるべきではありません。

検討

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

いくつかの任意の型RとFoo()を含まないいくつかの任意の契約C $の場合。

Tには、 Cに必要なすべてのセレクターが含まれますが、 Tの特定のインスタンス化には、 Fooを含む任意の他のセレクターも含まれる場合があります。

Barが、 Cの下で許容される構造体であり、 Fooという名前のフィールドがあるとします。

X(Bar)は違法なインスタンス化である可能性があります。 タイプにセレクターがないというコントラクトを指定する方法がなければ、これは推測されたプロパティである必要があります。

X(Bar)のメソッドは、$ Foo X(Bar).R.Foo $として解決し続けることができます。 これにより、ジェネリック型の記述が可能になりますが、解決ルールの問題に慣れていない読者にとっては混乱を招く可能性があります。 Xのメソッド以外では、セレクターはあいまいなままなので、 interface { Foo() }はXのパラメーターに依存しませんが、 Xの一部のインスタンス化はそれを満たさない。

タイプパラメータの埋め込みを禁止する方が簡単です。

（ただし、これが許可される場合、 type S = io.Readerとして定義された埋め込みSのフィールド名がSであるのと同じ理由で、フィールド名はTになります。 Sであり、 Readerではありませんが、 Tインスタンス化する型は、必ずしも名前を持っている必要はないためです。）

@jimmyfrascheジェネリック型の埋め込みフィールドは、場所に少し厄介な部分がある場合でも、それらを許可するのに十分役立つと思います。 私の提案は、すべてのジェネリックコードで、埋め込み型がすべての可能なレベルですべての可能なフィールドとメソッドを定義していると想定することです。これにより、ジェネリックコード内で、非ジェネリック型のすべての埋め込みメソッドとフィールドが消去されます。

そのように与えられた：

type R struct(type T) {
    io.Reader
    T
}

Rのメソッドは、Readerを介して間接化せずにRのReadを呼び出すことはできません。 例えば：

func (r R) Do() {
     r.Read(buf)     // Illegal
     r.Reader.Read(buf)  // ok
}

これについて私が見ることができる唯一の欠点は、動的型が静的型よりも多くのメンバーを含む可能性があることです。 例えば：

func (r R) Do() {
    var x interface{} = r
    x.(io.Reader)    // Succeeds
}

@rogpeppe

これについて私が見ることができる唯一の欠点は、動的型が静的型よりも多くのメンバーを含む可能性があることです。

これは型パラメーターに直接当てはまるので、パラメトリック型でも問題ないと思います。 @jimmyfrascheが提示した問題の解決策は、パラメーター化された型の目的のメソッドセットをコントラクトに入れることかもしれないと思います。

contract C(t T) {
  interface { Foo() } (X(T){})
  // ...
}

type X(type T C) struct {
  R // A regular type with method Foo()
  T // Some type parameter
}
// X defines some methods other than Foo(),
// some of which invoke Foo.

これにより、 FooをX直接呼び出すことができます。 もちろん、これは「契約にローカル名がない」というルールに反することになります...

@stevenblenkinsopうーん、厄介な場合は、 Xを参照せずにそれを行うことができます

contract C(t T) {
  struct{ R; T }{}.Foo
}

Cは、もう少し緩くはありますが、 Xの実装にバインドされています。

あなたがそれをしなければ、あなたは書く

func (x X(T)) Fooer() interface { Foo() } {
  return x
}

コンパイルしますか？ 契約で保証をしない場合にも採用する必要があると思われる@rogpeppeのルールには従わないでしょう。 しかし、それは、十分なコントラクトなしで型引数を埋め込む場合、またはすべての埋め込みにのみ適用されますか？

単にそれを禁止する方が簡単でしょう。

Go2ドラフトが発表される前に、私はこの提案に取り組み始めました。

アナウンスを見たとき、喜んでスクラップする準備ができていましたが、ドラフトの複雑さにまだ不安を感じていたので、仕上げました。 それほど強力ではありませんが、よりシンプルです。 他に何もないとしても、それは盗む価値のあるビットを持っているかもしれません。

@ianlancetaylorの以前の提案の構文を拡張したものです。これは、私が始めたときに利用可能だったものです。 それは基本的なことではありません。 (type Tなどの構文または同等のものに置き換えることができます。 セマンティクスの表記法として構文が必要でした。

ここにあります： https ：//gist.github.com/jimmyfrasche/656f3f47f2496e6b49e041cd8ac716e4

ルールは、（1）型引数のIDがわかっているか、（2）メソッドが外部で呼び出し可能であると主張されない限り、埋め込み型パラメーターよりも深いところからプロモートされたメソッドを呼び出すことができないということです。タイプパラメータを制約するコントラクトでタイプします。 コンパイラーは、プロモートされたメソッドが外部型O内に持つ必要のある深さの上限と下限を判別し、それらを使用して、メソッドがOを埋め込む型で呼び出し可能かどうかを判別することもできます。つまり、他の促進された方法と競合する可能性があるかどうか。 同様のことが、呼び出し可能なメソッドを持つようにアサートされているすべての型パラメーターにも当てはまります。ここで、型パラメーター内のメソッドの深さの範囲は[0、inf）になります。

タイプパラメータの埋め込みは、完全に禁止するにはあまりにも便利なようです。 一つには、それは透明な構成を可能にしますが、それは埋め込みインターフェースのパターンでは許可されません。

また、契約の定義にも使用できる可能性があります。 *Tでメソッドが定義されている可能性のあるタイプT （ポインタータイプの場合もあります）の値を受け入れられるようにし、その値をインターフェイスでは、メソッドが*Tにある可能性があるため、必ずしもTをインターフェイスに配置することはできません。また、 *T Tインターフェイスに配置することはできません。 *Tには空のメソッドが設定されている可能性があります）。 ただし、次のようなラッパーがある場合

type Wrapper(type T) { T }

コントラクトがインターフェースを満たしていると言っている場合は、すべての場合にインターフェースに*Wrapper(T)を入れることができます。

あなたはただすることはできません

type Interface interface {
  SomeMethod(int) error
}

contract MightBeAPointer(t T) {
  Interface(t)
}

func Example(type T MightBeAPointer)(v T) {
  var i Interface = v
  // ...
}

誰かが電話をかけた場合に対処しようとしています

type S struct{}
func (s *S) SomeMethod(int) error { ... }
...
var s S
Example(S)(s)

SはInterfaceに変換できず、 *Sのみが変換できるため、これは機能しません。

明らかに、答えは「そうしないでください」かもしれません。 ただし、契約提案では、次のような契約について説明しています。

contract Contract(t T) {
    var _ error = t.SomeMethod(int(0))
}

Sは、 *Sと同様に、自動アドレス指定によりこの契約を満たします。 私が対処しようとしているのは、コントラクトのメソッド呼び出しとインターフェース変換の間の機能のギャップです。

とにかく、これは少し接線であり、タイプパラメータを埋め込むための1つの潜在的な用途を示しています。

再埋め込み、「構造体に埋め込むことができる」というのは、許可された場合にコントラクトがキャプチャしなければならないもう1つの制限だと思います。

検討：

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
}

type Embedded(type First, Second Embeddable) struct {
        First
        Second
}

// Error: First and Second both provide method Read.
// That must be diagnosed to the Embeddable contract, not the definition of Embedded itself.
type Boom = Embedded(*bytes.Buffer, *strings.Reader)

@bcmillsは、あいまいなセレクターを使用して型を埋め込むことが許可されているため、そのコントラクトがどのように解釈されるのかわかりません。

とにかく、既知のタイプのみを埋め込む場合は問題ありません。 タイプパラメータのみを埋め込む場合は問題ありません。 奇妙になる唯一のケースは、1つ以上の既知の型と1つ以上の型パラメーターを埋め込んだ場合と、既知の型のセレクターと型引数が互いに素でない場合のみです。

@bcmillsは、あいまいなセレクターを使用して型を埋め込むことが許可されているため、そのコントラクトがどのように解釈されるのかわかりません。

うーん、良い点。 エラーをトリガーするためのもう1つの制約がありません。¹

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
    var _ io.Reader = S{}
}

¹https ：//play.golang.org/p/3wSg5aRjcQc

これには、 XまたはYのいずれかが必要ですが、両方がio.Readerである必要はありません。 契約システムがそれを可能にするのに十分表現力があるのは興味深いことです。 そのような獣の型推論規則を理解する必要がないのはうれしいです。

しかし、それは実際には問題ではありません。

それはあなたがするときです

type S (type T C) struct {
  io.Reader
  T
}
func (s *S(T)) X() io.Reader {
  return s
}

Cが持っていない限り、 TはReadセレクターを持つことができるので、それはコンパイルに失敗するはずです

struct{ io.Reader; T }.Read

しかし、 Cがセレクターセットが互いに素であることを保証せず、 Sがセレクターを参照しない場合のルールは何でしょうか？ あいまいなセレクターを作成するタイプを除いて、すべてのインスタンス化Sがインターフェイスを満たすことは可能ですか？

あいまいなセレクターを作成するタイプを除いて、すべてのインスタンス化Sがインターフェイスを満たすことは可能ですか？

はい、そうです。 それはもっと深いことを意味するのだろうか...🤔

私は取り返しのつかないほど厄介なものを構築することができませんでしたが、非対称性は非常に不快であり、私を不安にさせます：

type I interface { /* ... */ }
a := G(A) // ok, A satisfies contract
var _ I = a // ok, no selector overlap
b := G(B) // ok, B satisfies contract
var _ = b // error, selector overlap

G0(B)がG1(B)を使用する場合のエラーメッセージが心配です。 。 。 Gn(B)を使用し、$ Gnがエラーの原因です。 。 。 。

FTR、埋め込みでタイプエラーをトリガーするためにあいまいなセレクターの問題を経験する必要はありません。

// Error: Duplicate field name Reader
type Boom = Embedded(*bytes.Reader, *strings.Reader)

埋め込みフィールド名は引数の型に基づいていると想定していますが、埋め込み型パラメーターの名前である可能性が高くなります。 これは、タイプエイリアスを埋め込み、フィールド名がエイリアスするタイプの名前ではなくエイリアスである場合と似ています。

これは、パラメータ化された型に関するセクションのドラフト設計で実際に指定されています。

パラメータ化された型が構造体であり、型パラメータが構造体のフィールドとして埋め込まれている場合、フィールドの名前は型引数の名前ではなく、型パラメータの名前になります。

type Lockable(type T) struct {
    T
    mu sync.Mutex
}

func (l *Lockable(T)) Get() T {
    l.mu.Lock()
    defer l.mu.Unlock()
    return l.T
}

（注：メソッド宣言にLockable（X）を記述した場合、これはうまく機能しません。メソッドはlTまたはlXを返す必要がありますか？おそらく、構造体への型パラメーターの埋め込みを禁止する必要があります。）

私はただ傍観者としてここに座って観察しています。 しかし、少し心配することもあります。

私が恥ずかしくないことの1つは、この議論の90％が私の頭上にあるということです。

ジェネリックスやパラメトリックポリモーフィズムが何であるかを知らずにソフトウェアを書くことで生計を立ててきた20年は、私が仕事を成し遂げることを妨げていないようです。

悲しいことに、私はGoを学ぶのに約1年前の時間しかかかりませんでした。 私はそれが急な学習曲線であり、生産的になるのに時間がかかりすぎると誤った仮定をしました。

私はもっ​​と間違っていたはずがない。

私は、週末以内にパフォーマンスの問題を抱えていたnode.jsサービスを完全に破壊するマイクロサービスを構築するために十分なGoを学ぶことができました。

皮肉なことに、私はただ遊んでいました。 私は囲碁で世界を征服することについて特に真剣ではありませんでした。

それでも、数時間以内に、私は自分の前かがみの敗北した姿勢から立ち上がっていることに気づきました。まるで、自分の席の端でアクションスリラーを見ているようでした。 私が構築していたAPIは非常に迅速に統合されました。 明らかにそのデザインが非常に実用的だったので、これは確かに私の貴重な時間を投資する価値のある言語であることに気づきました。

そして、それが私がGoについて気に入っていることです。 それは非常に速いです.....学ぶために。 私たちは皆、そのパフォーマンス能力を知っています。 しかし、それを学ぶことができる速度は、私が長年にわたって学んだ他の8つの言語とは比べものにならないほどです。

それ以来、私はGoの称賛を歌い続け、さらに4人の開発者にそれを気に入ってもらいました。 私は彼らと数時間座って何かを作ります。 結果はそれ自体を物語っています。

シンプルさ、そして学ぶスピード。 これらは、言語の真のキラー機能です。

何ヶ月にもわたるハードスログ学習を必要とするプログラミング言語は、多くの場合、彼らが引き付けようとしている開発者そのものを保持していません。 私たちにはやるべき仕事があり、毎日進歩を見たいと思っている雇用主（アジャイルに感謝し、感謝します）

ですから、Goチームが考慮に入れてほしいことが2つあります。

1）私たちが解決しようとしている日々の問題は何ですか？

ジェネリックスや、ジェネリックスと呼ばれるものによって解決されるショーストッパーを使用した、実際の例を見つけることができないようです。

問題のある日常のタスクのクックブックスタイルの例と、これらの言語変更の提案によってどのように改善されるかについての例。

2）Goの他のすべての優れた機能と同様に、シンプルに保ちます

ここにいくつかの信じられないほどインテリジェントなコメントがあります。 しかし、私のような一般的なプログラミングに日常的にGoを使用している開発者の大多数は、現状に完全に満足していて生産的であると確信しています。

おそらく、そのような高度な機能を有効にするためのコンパイラの議論ですか？ '-ハードコア'

コンパイラのパフォーマンスに悪影響を与えたら、本当に悲しいです。 ただ言って

そして、それが私がGoについて気に入っていることです。 それは非常に速いです.....学ぶために。 私たちは皆、そのパフォーマンス能力を知っています。 しかし、それを学ぶことができる速度は、私が長年にわたって学んだ他の8つの言語とは比べものにならないほどです。

同意します。 完全にコンパイルされた言語でのパワーとシンプルさの組み合わせは、完全にユニークなものです。 私は間違いなくGoがそれを失いたくないし、ジェネリックが欲しいのと同じくらい、その費用でそれだけの価値があるとは思わない。 しかし、それを失う必要はないと思います。

ジェネリックスや、ジェネリックスと呼ばれるものによって解決されるショーストッパーを使用した、実際の例を見つけることができないようです。

ジェネリックスの主な使用例は2つあります。バイナリツリー、セット、 sync.Mapなどの複雑なデータ構造のタイプセーフなボイラープレート除去と、ベースで動作する_compile-time_タイプセーフ関数を作成する機能です。メモリ内のレイアウトではなく、純粋に引数の機能に基づいています。 言語の単純さを完全に壊さずにサポートを追加することが不可能な場合、私ができることを気にしないいくつかのより素晴らしいことがありますが、私はそれらを行うことができなくてもかまいません。

正直なところ、この言語にはすでにかなり乱用されている機能があります。 それらが悪用されない主な理由は、ほとんどの場合、そのようなコードのクリーンで見つけやすい例を提供する標準ライブラリと組み合わせて、「慣用的な」コードを書くというGoの文化であると私は思います。 ジェネリックスを標準ライブラリにうまく利用することは、それらを実装する際の優先事項であることは間違いありません。

@camstuart

ジェネリックスや、ジェネリックスと呼ばれるものによって解決されるショーストッパーを使用した、実際の例を見つけることができないようです。

ジェネリックスは、自分でコードを書く必要がないようにするためのものです。 したがって、別のリンクリスト、バイナリツリー、deque、またはpriority-queueを再度実装する必要はありません。 並べ替えアルゴリズム、分割アルゴリズム、回転アルゴリズムなどを実装する必要はありません。データ構造は標準コレクション（たとえば、リストのマップ）を構成し、処理は標準アルゴリズム（データ、分割、と回転）。 これらのコンポーネントを再利用できる場合、優先度キューまたはパーティショニングアルゴリズムを再実装するたびに、間違ってバグが発生する可能性があるため、エラー率が低下します。

ジェネリックとは、書くコードを減らし、再利用することを意味します。 つまり、標準のよく維持されたライブラリ関数と抽象データ型をより多くの状況で使用できるため、独自に作成する必要はありません。

さらに良いことに、これらはすべてGoで技術的に実行できますが、コンパイル時の型安全性がほぼ完全に失われ、実行時のオーバーヘッドが大きくなる可能性があります。 ジェネリックスは、これらの欠点のどちらもなしでそれを行うことができます。

ジェネリック関数の実装：

/*

* "generic" is a KIND of types, just like "struct", "map", "interface", etc...
* "T" is a generic type (a type of kind generic).
* var t = T{int} is a value of type T, values of generic types looks like a "normal" type

*/

type T generic {
    int
    float64
    string
}

func Sum(a, b T{}) T{} {
    return a + b
}

関数の呼び出し元：

Sum(1, 1) // 2
// same as:
Sum(T{int}(1), T{int}(1)) // 2

ジェネリック構造体の実装：

type ItemT generic {
    interface{}
}

type List struct {
    l []ItemT{}
}

func NewList(t ItemT) *List {
    l := make([]t)
    return &List{l}
}

func (p *List) Push(item ItemT{}) {
    p.l = append(p.l, item)
}

発信者：

list := NewList(ItemT{int})
list.Push(42)

Swiftを学んでいて好きではないが、Go、C、Javaなどの他の言語での豊富な経験を持つ人として。 ジェネリックス（またはテンプレート、またはあなたがそれを呼びたいもの）はGo言語に追加するのは良いことではないと私は本当に信じています。

たぶん私は現在のバージョンのGoの経験が豊富ですが、他の人が書いたコードを理解するのがより難しいという点で、これはC ++への回帰のように感じます。 型の古典的なTプレースホルダーは、関数が何をしようとしているのかを理解するのを非常に難しくします。

これは人気のある機能リクエストなので、着地したら対処できますが、2セント（意見）を追加したいと思いました。

@jlubawy
リンクリストやクイックソートアルゴリズムを実装する必要がない別の方法を知っていますか？ Alexander Stepanovが指摘しているように、ほとんどのプログラマーは「最小」関数と「最大」関数を正しく定義できないため、多くのデバッグ時間をかけずに、より複雑なアルゴリズムを正しく実装する必要があります。 私はむしろ、これらのアルゴリズムの標準バージョンをライブラリから引き出して、自分が持っているタイプに適用したいと思っています。 どのような選択肢がありますか？

@jlubawy

またはテンプレート、またはあなたがそれを呼びたいものは何でも

すべては実装に依存します。 C ++テンプレートについて話している場合は、そうです。一般的に理解するのは困難です。 それらを書くことさえ難しいです。 一方、C＃ジェネリックを採用する場合、それはまったく別のことです。 コンセプト自体はここでは問題ではありません。

ご存じない方のために、GoチームはGo2.0のドラフトを発表しました。
https://golang.org/s/go2designs

Go 2.0（契約）のジェネリックデザインのドラフトがあります。 あなたは彼らのWikiを見てフィードバックを与えることをお勧めします。

これは関連するセクションです：

ジェネリック

• 概要
• ドラフトデザイン
• Wikiフィードバックページ

ドラフトを読んだ後、私は尋ねます：

なぜ

T：追加可能

「契約追加可能を実装するタイプT」を意味しますか？ 新しいものを追加する理由
そのためのインターフェースがすでにある場合のコンセプトは？ インターフェイスの割り当ては
ビルド時間をチェックインしたので、私たちはすでに何も必要としない手段を持っています
ここに追加の概念。 この用語を使用して、次のように言うことができます。
インターフェイスAddableを実装するタイプT。 さらに、T：_またはT：Any
（特別なキーワードまたはinterface {}の組み込みエイリアスである）
トリック。

そのようなもののほとんどを再実装する理由がわかりません。 しません
センスと冗長性があります（冗長性はエラーの新しい処理であるため）
パニックの処理）。

2018-09-14 6:15 GMT-05：00コアラヨン[email protected] ：

ご存じない方のために、GoチームはGo2.0のドラフトを発表しました。
https://golang.org/s/go2designs

Go 2.0（契約）のジェネリックデザインのドラフトがあります。 あなたが望むかもしれません
見て、フィードバックを与えるために
https://github.com/golang/go/wiki/Go2GenericsFeedback on their Wiki
https://github.com/golang/go/wiki/Go2GenericsFeedback 。

これは関連するセクションです：

ジェネリック

• 概要
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [ドラフトデザイン]（https://go.googlesource.com/proposal/+/master/design/
  go2draft-contracts.md）
• Wikiフィードバックページ
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment-421326634 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
。

-
これは、TripleMintで使用されるメール署名のテストです。

編集：「[...]は、特定の要件が必要ない場合にトリックを実行します
タイプ引数」。

2018-09-17 11:10 GMT-05：00 Luis Masuelli [email protected] ：

ドラフトを読んだ後、私は尋ねます：

なぜ

T：追加可能

「契約追加可能を実装するタイプT」を意味しますか？ 新しいものを追加する理由
そのためのインターフェースがすでにある場合のコンセプトは？ インターフェイスの割り当ては
ビルド時間をチェックインしたので、私たちはすでに何も必要としない手段を持っています
ここに追加の概念。 この用語を使用して、次のように言うことができます。
インターフェイスAddableを実装するタイプT。 さらに、T：_またはT：Any
（特別なキーワードまたはinterface {}の組み込みエイリアスである）
トリック。

そのようなもののほとんどを再実装する理由がわかりません。 しません
センスと冗長性があります（冗長性はエラーの新しい処理であるため）
パニックの処理）。

2018-09-14 6:15 GMT-05：00コアラヨン[email protected] ：

ご存じない方のために、GoチームはGo2.0のドラフトを発表しました。
https://golang.org/s/go2designs

Go 2.0（契約）のジェネリックデザインのドラフトがあります。 してもいいです
見て、フィードバックを送りたい
https://github.com/golang/go/wiki/Go2GenericsFeedback on their Wiki
https://github.com/golang/go/wiki/Go2GenericsFeedback 。

これは関連するセクションです：

ジェネリック

• 概要
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [ドラフトデザイン]（https://go.googlesource.com/p
  roposal / + / master / design / go2draft-contracts.md
  https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
  ）。
• Wikiフィードバックページ
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
コメントしたのでこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/golang/go/issues/15292#issuecomment-421326634 、またはミュート
スレッド
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
。

-
これは、TripleMintで使用されるメール署名のテストです。

-
これは、TripleMintで使用されるメール署名のテストです。

@ luismasuelli-jobsity Goで一般的な実装の履歴を正しく読んだ場合、コントラクトを導入する理由は、インターフェイスでの演算子のオーバーロードを望まなかったためと思われます。

最終的に拒否された以前の提案では、インターフェイスを使用してパラメトリックポリモーフィズムを制約していましたが、インターフェイスで定義できないため、このような関数で「+」などの一般的な演算子を使用できなかったため、拒否されたようです。 コントラクトを使用すると、 t == tまたはt + tを記述できるため、型が等式または加算などをサポートする必要があることを示すことができます。

編集：また、Goは複数の型パラメーターインターフェイスをサポートしていないため、ある意味でGoは、型クラスを2つの別個のもの、関数型パラメーターを相互に関連付けるコントラクト、およびメソッドを提供するインターフェイスに分離しました。 それが失うのは、複数の型に基づいて型クラスの実装を選択する機能です。 インターフェイスまたはコントラクトのみを使用する必要がある場合は間違いなく簡単ですが、両方を一緒に使用する必要がある場合はより複雑になります。

T:Addableが「コントラクトAddableを実装するタイプT」を意味するのはなぜですか？

それは実際にはそれが意味することではありません。 1つの型引数についてはそのように見えます。 ドラフトの他の場所では、関数ごとに1つのコントラクトしか持てないというコメントがあります。これが主な違いです。コントラクトは、実際には、関数のタイプだけでなく、関数のタイプに関するステートメントです。 たとえば、

func Example(type K, V someContract)(k K, v V) V

あなたは次のようなことをすることができます

contract someContract(k K, v V) {
  k.someMethod(v)
}

これにより、関数シグニチャで型を冗長に指定することなく、複数の型の調整が大幅に簡素化されます。 彼らは「不思議なことに繰り返される一般的なパターン」を避けようとしていることを忘れないでください。 たとえば、型を制約するために使用されるパラメーター化されたインターフェースを持つ同じ関数は、次のようになります。

type someMethoder(V) interface {
  someMethod(V)
}

func Example(type K: someMethoder(V), V)(k K, v V) V

これはちょっと厄介です。 ただし、コントラクトの「引数」は、関数がパラメーターを入力するのと同じ数のコントラクトを持っている場合、コンパイラーによって自動入力されるため、コントラクト構文を使用すると、必要に応じてこれを実行できます。 ただし、必要に応じて手動で指定できます。つまり、この状況では特に有用ではありませんが、本当に必要な場合はfunc Example(type K, V someContract(K, V))(k K, v V) Vを実行できます。

コントラクトが個々の引数ではなく関数全体に関するものであることを明確にする1つの方法は、名前に基づいてそれらを単純に関連付けることです。 例えば、

contract Example(k K, v V) {
  k.someMethod(v)
}

func Example(type K, V)(k K, v V) V

上記と同じになります。 ただし、欠点は、コントラクトが再利用できず、コントラクトの引数を手動で指定する機能が失われることです。

編集：彼らが不思議な繰り返しパターンを解決したい理由をさらに示すために、彼らが参照し続けた最短経路問題を考えてみましょう。 パラメータ化されたインターフェイスを使用すると、定義は次のようになります。

type E(Node) interface {
  Nodes() []Node
}

type N(Edge) interface {
  Edges() (from, to Edge)
}

type Graph(type Node: N(Edge), Edge: E(Node)) struct { ... }
func New(type Node: N(Edge), Edge: E(Node))(nodes []Node) *Graph(Node, Edge) { ... }
func (*Graph(Node, Edge)) ShortestPath(from, to Node) []Edge { ... }

個人的には、関数のコントラクトを指定する方法が好きです。 私は実際のコントラクト仕様として「通常の」関数本体を使用することにあまり熱心ではありませんが、コントラクトを自動単純化するある種のgofmtのような単純化を導入することで、潜在的な問題の多くを解決できると思います。無関係な部品。 次に、関数本体をコピーして単純化し、そこから変更することができます。 残念ながら、これを実装することがどれほど可能かはわかりません。

ただし、いくつかのことを指定するのはまだ少し厄介であり、コントラクトとインターフェースの間の明らかな重複はまだ少し奇妙に思えます。

「CRTP」バージョンは、はるかに明確で、より明確で、操作が簡単です（一連の変数に対する既存のコントラクト間の関係を定義するためにのみ存在するコントラクトを作成する必要はありません）。 確かに、それはアイデアに長年精通しているだけかもしれません。

明確化。 ドラフト設計により、機能とタイプの両方にコントラクトを適用できます。

"" "
インターフェイスまたはコントラクトのみを使用する必要がある場合は間違いなく簡単ですが、両方を一緒に使用する必要がある場合はより複雑になります。
"" "

コントラクト内で（演算子と関数だけでなく、DRYを許可する）1つ以上のインターフェイスを参照できる限り、この問題（および私の主張）は解決されます。 契約書を読み間違えたり、完全に読んでいない可能性があります。また、上記の機能がサポートされていて、気づかなかった可能性もあります。 そうでない場合は、そうする必要があります。

次のことができませんか？

contract Example(t T, v V) {
  t.(interface{
    SomeMethod() V
  })
}

コントラクトが宣言されているのと同じパッケージから識別子を参照できないという制限があるため、他の場所で宣言されているインターフェイスを使用することはできませんが、これは可能です。 または、その制限を取り除くこともできます。 少し恣意的なようです。

@DeedleFakeいいえ、どのインターフェイスタイプもタイプアサートできるためです（実行時にパニックになる可能性がありますが、コントラクトは実行されません）。 ただし、代わりに割り当てを使用できます。