CL https://golang.org/cl/22057 erwähnt dieses Problem.

Lassen Sie mich alle vorsorglich an unsere https://golang.org/wiki/NoMeToo-Richtlinie erinnern. Die Emoji-Party ist oben.

Es gibt eine Zusammenfassung der Go Generics-Diskussionen , die versucht, einen Überblick über Diskussionen von verschiedenen Orten zu geben. Es enthält auch einige Beispiele zur Lösung von Problemen, bei denen Sie Generika verwenden möchten.

Der verlinkte Vorschlag enthält zwei „Anforderungen“, die die Umsetzung erschweren und die Typensicherheit verringern können:

• Definieren Sie generische Typen basierend auf Typen, die erst bei ihrer Instanziierung bekannt sind.
• Erfordern Sie keine explizite Beziehung zwischen der Definition eines generischen Typs oder einer generischen Funktion und ihrer Verwendung. Das heißt, Programme sollten nicht explizit sagen müssen, dass Typ T generisches G implementiert.

Diese Anforderungen scheinen z. B. ein dem Trait-System von Rust ähnliches System auszuschließen, bei dem generische Typen durch Trait-Grenzen eingeschränkt werden. Warum werden diese benötigt?

Es ist verlockend, Generika auf einer sehr niedrigen Ebene in die Standardbibliothek einzubauen, wie in C++ std::basic_string, std::Zuordner>. Das hat seine Vorteile – sonst würde es niemand tun – aber es hat weitreichende und manchmal überraschende Auswirkungen, wie in unverständlichen C++-Fehlermeldungen.

Das Problem in C++ ergibt sich aus der Typüberprüfung des generierten Codes. Vor der Codegenerierung ist eine zusätzliche Typprüfung erforderlich. Der C++- Konzeptvorschlag ermöglicht dies, indem er dem Autor von generischem Code erlaubt, die Anforderungen eines generischen Typs zu spezifizieren. Auf diese Weise kann die Kompilierung vor der Codegenerierung fehlschlagen und einfache Fehlermeldungen können ausgegeben werden. Das Problem mit C++-Generika (ohne Konzepte) besteht darin, dass der generische Code die Spezifikation des generischen Typs _ist_. Dadurch entstehen die unverständlichen Fehlermeldungen.

Generischer Code sollte nicht die Spezifikation eines generischen Typs sein.

@tamird Es ist ein wesentliches Merkmal der Schnittstellentypen von Go, dass Sie einen Nicht-Schnittstellentyp T definieren und später einen Schnittstellentyp I definieren können, sodass T I implementiert. Siehe https://golang.org/doc/faq#implements_interface . Es wäre widersprüchlich, wenn Go eine Form von Generika implementieren würde, für die ein generischer Typ G nur mit einem Typ T verwendet werden könnte, der ausdrücklich sagt: „Ich kann verwendet werden, um G zu implementieren.“

Ich bin mit Rust nicht vertraut, aber ich kenne keine Sprache, in der T explizit angeben muss, dass sie zur Implementierung von G verwendet werden kann. Die beiden von Ihnen erwähnten Anforderungen bedeuten nicht, dass G keine Anforderungen an T stellen kann, nur da I Anforderungen an T stellt. Die Anforderungen bedeuten lediglich, dass G und T unabhängig voneinander geschrieben werden können. Das ist eine sehr wünschenswerte Funktion für Generika, und ich kann mir nicht vorstellen, darauf zu verzichten.

@ianlancetaylor https://doc.rust-lang.org/book/traits.html erklärt Rusts Eigenschaften. Obwohl ich denke, dass sie im Allgemeinen ein gutes Modell sind, würden sie schlecht zu Go passen, wie es heute existiert.

@sbunce Ich dachte auch, dass Konzepte die Antwort sind, und Sie können die Idee sehen, die in den verschiedenen Vorschlägen vor dem letzten verstreut ist. Aber es ist entmutigend, dass Konzepte ursprünglich für das geplant waren, was C++ 11 wurde, und es ist jetzt 2016, und sie sind immer noch umstritten und nicht besonders nahe daran, in die C++-Sprache aufgenommen zu werden.

Wäre die wissenschaftliche Literatur für Hinweise zur Bewertung von Ansätzen wertvoll?

Das einzige Papier, das ich zu diesem Thema gelesen habe, ist Profitieren Entwickler von generischen Typen? (Entschuldigung, Paywall, Sie könnten sich zu einem PDF-Download googlen), der Folgendes zu sagen hatte

Folglich eine konservative Interpretation des Experiments
ist, dass generische Typen als Kompromiss betrachtet werden können
zwischen den positiven Dokumentationsmerkmalen und der
negative Dehnbarkeitseigenschaften. Der spannende Teil von
Die Studie ist, dass sie eine Situation zeigte, in der die Verwendung von a
(stärker) statische Art System hatte einen negativen Einfluss auf die
Entwicklungszeit bei gleichzeitig erwartetem Nutzen
fit – die Verringerung der Zeit zur Behebung von Typfehlern – erschien nicht.
Wir denken, dass solche Aufgaben bei zukünftigen Experimenten helfen könnten
Identifizierung der Auswirkungen von Typensystemen.

Ich sehe auch, dass https://github.com/golang/go/issues/15295 auch auf Lightweight, Flexible Object-Oriented Generics verweist.

Wenn wir uns bei der Entscheidung auf die Wissenschaft stützen würden, wäre es meiner Meinung nach besser, im Voraus eine Literaturrecherche durchzuführen und wahrscheinlich frühzeitig zu entscheiden, ob wir empirische Studien anders gewichten würden als solche, die sich auf Beweise stützen.

Siehe: http://dl.acm.org/citation.cfm?id=2738008 von Barbara Liskov:

Die Unterstützung für generische Programmierung in modernen objektorientierten Programmiersprachen ist umständlich und es fehlt ihr an wünschenswerter Ausdruckskraft. Wir führen einen ausdrucksstarken Generizitätsmechanismus ein, der die Ausdruckskraft erhöht und die statische Prüfung stärkt, während er in gängigen Anwendungsfällen leicht und einfach bleibt. Wie Typklassen und -konzepte erlaubt der Mechanismus existierenden Typen, Typeinschränkungen rückwirkend zu modellieren. Für die Ausdruckskraft legen wir Modelle als benannte Konstrukte offen, die definiert und explizit ausgewählt werden können, um Einschränkungen zu bezeugen; Bei der üblichen Verwendung von Generizität weisen Typen jedoch implizit Einschränkungen ohne zusätzlichen Programmieraufwand auf.

Ich denke, was sie dort gemacht haben, ist ziemlich cool - es tut mir leid, wenn dies der falsche Ort ist, um aufzuhören, aber ich konnte keinen Ort zum Kommentieren in /proposals finden und ich habe hier kein passendes Problem gefunden.

Es könnte interessant sein, einen oder mehrere experimentelle Transpiler zu haben - einen Go-Generika-Quellcode für Go 1.xy-Quellcode-Compiler.
Ich meine - zu viel Gerede/Argumente-für-meine-Meinung, und niemand schreibt Quellcode, der _versucht_ , _irgendeine Art_ Generika für Go zu implementieren.

Nur um Wissen und Erfahrungen mit Go und Generika zu sammeln - um zu sehen, was funktioniert und was nicht.
Wenn alle Go-Generika-Lösungen nicht wirklich gut sind, dann; Keine Generika für Go.

Kann der Vorschlag auch die Auswirkungen auf die Binärgröße und den Speicherbedarf beinhalten? Ich würde erwarten, dass es für jeden konkreten Werttyp eine Codeduplizierung geben wird, damit Compileroptimierungen daran arbeiten. Ich hoffe auf eine Garantie, dass es bei konkreten Pointer-Typen zu keiner Code-Duplizierung kommt.

Ich biete eine Pugh-Entscheidungsmatrix an. Meine Kriterien umfassen die Auswirkungen auf die Sichtbarkeit (Komplexität der Quelle, Größe). Ich habe auch eine Rangfolge der Kriterien erzwungen, um die Gewichtungen für die Kriterien zu bestimmen. Ihre eigenen können natürlich variieren. Ich habe "Schnittstellen" als Standardalternative verwendet und dies mit "Kopieren/Einfügen"-Generika, vorlagenbasierten Generika (ich hatte so etwas im Sinn wie die D-Sprache funktioniert) und etwas, das ich Runtime-Instanziierungsstil-Generika genannt habe, verglichen. Ich bin mir sicher, dass dies eine gewaltige Vereinfachung ist. Nichtsdestotrotz könnte es einige Ideen zur Bewertung von Entscheidungen anregen ... dies sollte ein öffentlicher Link zu meinem Google Sheet sein, hier

Pingen Sie @yizhouzhang und @andrewcmyers , damit sie ihre Meinung zu Gattungen wie Generika in Go äußern können. Klingt so, als könnte es gut zusammenpassen :)

Das generische Design, das wir für Genus entwickelt haben, verfügt über eine statische, modulare Typprüfung, erfordert keine vorherige Deklaration, dass Typen eine Schnittstelle implementieren, und verfügt über eine angemessene Leistung. Ich würde es mir auf jeden Fall ansehen, wenn Sie an Generika für Go denken. Es scheint nach meinem Verständnis von Go gut zu passen.

Hier ist ein Link zu dem Papier, für das kein Zugriff auf die ACM Digital Library erforderlich ist:
http://www.cs.cornell.edu/andru/papers/genus/

Die Genus-Homepage ist hier: http://www.cs.cornell.edu/projects/genus/

Wir haben den Compiler noch nicht öffentlich veröffentlicht, aber wir planen, dies ziemlich bald zu tun.

Beantworten Sie gerne alle Fragen, die die Leute haben.

In Bezug auf die Entscheidungsmatrix von @mandolyte erzielt Genus eine 17, gleichauf auf Platz 1. Ich würde jedoch einige weitere Kriterien hinzufügen, um zu bewerten. Zum Beispiel ist die modulare Typprüfung wichtig, wie andere wie @sbunce oben beobachtet haben, aber vorlagenbasierten Schemata fehlt es. Der technische Bericht für das Genus-Papier enthält auf Seite 34 eine viel größere Tabelle, in der verschiedene Generika-Designs verglichen werden.

Ich habe gerade das gesamte Dokument Summary of Go Generics durchgesehen, das eine hilfreiche Zusammenfassung früherer Diskussionen war. Der Generics-Mechanismus in Genus leidet meines Erachtens nicht unter den Problemen, die für C++, Java oder C# identifiziert wurden. Genus-Generika werden anders als in Java reifiziert, sodass Sie Typen zur Laufzeit herausfinden können. Sie können auch primitive Typen instanziieren, und Sie erhalten kein implizites Boxing an den Stellen, an denen Sie es wirklich nicht wollen: Arrays von T, wobei T ein Primitiv ist. Das Typsystem ist Haskell und Rust am nächsten – eigentlich etwas leistungsfähiger, aber meiner Meinung nach auch intuitiv. Primitive Spezialisierung ala C# wird derzeit in Genus nicht unterstützt, könnte es aber sein. In den meisten Fällen kann die Spezialisierung zur Verbindungszeit bestimmt werden, sodass eine echte Laufzeitcodegenerierung nicht erforderlich wäre.

CL https://golang.org/cl/22163 erwähnt dieses Problem.

Eine Möglichkeit, generische Typen einzuschränken, ohne dass neue Sprachkonzepte hinzugefügt werden müssen: https://docs.google.com/document/d/1rX4huWffJ0y1ZjqEpPrDy-kk-m9zWfatgCluGRBQveQ/edit?usp=sharing.

Genus sieht wirklich cool aus und ist eindeutig ein wichtiger Fortschritt der Kunst, aber ich sehe nicht, wie es auf Go zutreffen würde. Hat jemand eine Skizze, wie es sich in das Go-Typ-System / die Philosophie integrieren würde?

Das Problem ist, dass das Go-Team Versuche abblockt. Der Titel bringt die Absichten des Go-Teams klar zum Ausdruck. Und als wäre das noch nicht genug, um alle Abnehmer abzuschrecken, machen die von ian geforderten Eigenschaften eines so breiten Bereichs in den Vorschlägen von ian deutlich, dass Generika Sie nicht wollen, wenn Sie Generika wollen. Es ist idiotisch, auch nur den Versuch zu unternehmen, mit dem Go-Team in Dialog zu treten. Für diejenigen, die auf der Suche nach Generika sind, sage ich die Sprache brechen. Beginnen Sie eine neue Reise – viele werden folgen. Ich habe bereits einige großartige Arbeit gesehen, die in Gabeln geleistet wurde. Organisiert euch, versammelt euch um eine Sache

Wenn jemand versuchen möchte, eine Generika-Erweiterung für Go auf der Grundlage des Genus-Designs zu entwickeln, helfen wir gerne weiter. Wir kennen Go nicht gut genug, um ein Design zu entwickeln, das mit der bestehenden Sprache harmoniert. Ich denke, der erste Schritt wäre ein Strohmann-Designvorschlag mit ausgearbeiteten Beispielen.

@andrewcmyers hofft, dass @ianlancetaylor dabei mit dir zusammenarbeiten wird. Nur ein paar Beispiele zum Anschauen zu haben, würde viel helfen.

Ich habe das Genus-Papier gelesen. Soweit ich es verstehe, scheint es nett für Java zu sein, scheint aber nicht für Go geeignet zu sein.

Ein Schlüsselaspekt von Go ist, dass beim Schreiben eines Go-Programms das meiste, was Sie schreiben, Code ist. Dies unterscheidet sich von C++ und Java, wo viel mehr von dem, was Sie schreiben, Typen sind. Bei Genus scheint es hauptsächlich um Typen zu gehen: Sie schreiben eher Einschränkungen und Modelle als Code. Das Typensystem von Go ist sehr, sehr einfach. Das Typensystem von Genus ist weitaus komplexer.

Die Ideen der rückwirkenden Modellierung scheinen, obwohl sie für Java eindeutig nützlich sind, überhaupt nicht zu Go zu passen. Es werden bereits Adaptertypen verwendet, um vorhandene Typen mit Schnittstellen abzugleichen; bei der Verwendung von Generika sollte nichts weiter benötigt werden.

Es wäre interessant zu sehen, wie diese Ideen auf Go angewendet werden, aber ich bin nicht optimistisch, was das Ergebnis angeht.

Ich bin kein Go-Experte, aber sein Typsystem scheint nicht einfacher zu sein als Java vor der Generik. Die Typsyntax ist auf nette Weise etwas leichter, aber die zugrunde liegende Komplexität scheint ungefähr gleich zu sein.

In Genus sind Einschränkungen Typen, aber Modelle sind Code. Modelle sind Adapter, aber sie passen sich an, ohne eine Schicht tatsächlicher Verpackung hinzuzufügen. Dies ist sehr nützlich, wenn Sie beispielsweise ein ganzes Array von Objekten an eine neue Oberfläche anpassen möchten. Durch rückwirkende Modellierung können Sie das Array als ein Array von Objekten behandeln, die die gewünschte Schnittstelle erfüllen.

Ich wäre nicht überrascht, wenn es im typtheoretischen Sinne komplizierter wäre als Java (vorgeneriert), obwohl es in der Praxis einfacher zu verwenden ist.

Abgesehen von der relativen Komplexität sind sie so unterschiedlich, dass Genus sie nicht 1:1 abbilden konnte. Keine Untertypisierung scheint groß zu sein.

Wenn Sie interessiert sind:

Die kürzeste Zusammenfassung der relevanten philosophischen / gestalterischen Unterschiede, die ich erwähnt habe, ist in den folgenden FAQ-Einträgen enthalten:

• 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

Im Gegensatz zu den meisten Sprachen ist die Go-Spezifikation sehr kurz und klar, was die relevanten Eigenschaften des Typsystems betrifft, beginnen Sie bei https://golang.org/ref/spec#Constants und gehen Sie direkt durch bis zum Abschnitt mit dem Titel „Blocks“ (alles weniger als 11 gedruckte Seiten).

Im Gegensatz zu Java- und C#-Generika basiert der Genus-Generika-Mechanismus nicht auf Subtypisierung. Andererseits scheint es mir, dass Go Subtyping hat, aber strukturelle Subtyping. Das passt auch gut zum Genus-Ansatz, der einen strukturellen Charakter hat, anstatt sich auf vordeklarierte Beziehungen zu verlassen.

Ich glaube nicht, dass Go eine strukturelle Subtypisierung hat.

Während zwei Typen, deren zugrunde liegender Typ identisch ist, daher identisch sind
können gegeneinander ausgetauscht werden, https://play.golang.org/p/cT15aQ-PFr

Dies erstreckt sich nicht auf zwei Typen, die eine gemeinsame Teilmenge von Feldern teilen,
https://play.golang.org/p/KrC9_BDXuh.

Am Do, 28. April 2016 um 13:09 Uhr, Andrew Myers [email protected]
schrieb:

Im Gegensatz zu Java- und C#-Generika basiert der Genus-Generika-Mechanismus nicht auf
Subtypisierung. Andererseits scheint es mir, dass Go Subtyping hat,
aber strukturelle Subtypisierung. Das passt auch gut zum Genus-Ansatz,
die einen strukturellen Geschmack hat, anstatt sich auf vordeklarierte zu verlassen
Beziehungen.

—
Sie erhalten dies, weil Sie diesen Thread abonniert haben.
Antworten Sie direkt auf diese E-Mail oder zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment -215298127

Danke, ich habe einen Teil der Sprache darüber falsch interpretiert, wann Typen Schnittstellen implementieren. Eigentlich sieht es für mich so aus, als ob Go-Schnittstellen mit einer bescheidenen Erweiterung als Beschränkungen im Genus-Stil verwendet werden könnten.

Genau aus diesem Grund habe ich Sie angepingt, Genus scheint ein viel besserer Ansatz zu sein als Java/C#-ähnliche Generika.

Es gab einige Ideen zur Spezialisierung auf die Schnittstellentypen; zB die _Paketvorlagen_ Ansatz "Vorschläge" 1 2 sind Beispiele dafür.

tl;dr; Das generische Paket mit Schnittstellenspezialisierung würde folgendermaßen aussehen:

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

Version 1. mit paketbezogener Spezialisierung:

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

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

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

Version 2. die deklarationsbezogene Spezialisierung:

package main
import set

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

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

Die paketbezogenen Generika werden Menschen daran hindern, das Generikasystem erheblich zu missbrauchen, da die Nutzung auf grundlegende Algorithmen und Datenstrukturen beschränkt ist. Es verhindert grundsätzlich das Erstellen neuer Sprachabstraktionen und Funktionscodes.

Die deklarationsbezogene Spezialisierung hat mehr Möglichkeiten auf Kosten, wodurch sie anfälliger für Missbrauch ist und ausführlicher ist. Aber Funktionscode wäre möglich, zB:

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]]

Der Ansatz der Schnittstellenspezialisierung hat interessante Eigenschaften:

• Bereits existierende Pakete, die Schnittstellen verwenden, wären spezialisierbar. zB wäre ich in der Lage, sort.Sort[[Interface:MyItems]](...) aufzurufen und die Sortierarbeit für den konkreten Typ statt für die Schnittstelle zu haben (mit potenziellen Gewinnen durch Inlining).
• Das Testen wird vereinfacht, ich muss nur sicherstellen, dass der generische Code mit Schnittstellen funktioniert.
• Es ist einfach zu erklären, wie es funktioniert. dh stellen Sie sich vor, dass [[E: int]] alle Deklarationen von E durch int ersetzt.

Bei der paketübergreifenden Arbeit treten jedoch Ausführlichkeitsprobleme auf:

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]]()
    ...
}

_Natürlich ist das Ganze einfacher zu formulieren als zu realisieren. Intern gibt es wahrscheinlich haufenweise Probleme und Wege, wie es funktionieren könnte._

_PS, an die Nörgler über den langsamen Fortschritt bei Generika, ich applaudiere dem Go-Team dafür, dass es mehr Zeit auf Probleme verwendet, die einen größeren Nutzen für die Community haben, z. B. Compiler-/Laufzeitfehler, SSA, GC, http2._

@egonelbre Ihr Argument, dass Generika auf Paketebene "Missbrauch" verhindern, ist ein wirklich wichtiger Punkt, den die meisten Leute meiner Meinung nach übersehen. Das und ihre relative semantische und syntaktische Einfachheit (nur die Paket- und Importkonstrukte sind betroffen) machen sie für Go sehr attraktiv.

@andrewcymyers Interessant, dass Go-Schnittstellen Ihrer Meinung nach als Beschränkungen im Genus-Stil funktionieren. Ich hätte gedacht, dass sie immer noch das Problem haben, dass Sie mit ihnen keine Multi-Type-Parameter-Constraints ausdrücken können.

Eine Sache, die mir jedoch gerade klar geworden ist, ist, dass Sie in Go eine Schnittstelle inline schreiben können. Mit der richtigen Syntax könnten Sie also die Schnittstelle in den Geltungsbereich aller Parameter versetzen und Multiparameter-Einschränkungen erfassen:

type [V, E] Graph [V interface { Edges() E }, E interface { Endpoints() (V, V) }] ...

Ich denke, das größere Problem mit Schnittstellen als Einschränkungen ist, dass Methoden in Go nicht so allgegenwärtig sind wie in Java. Eingebaute Typen haben keine Methoden. Es gibt keinen Satz universeller Methoden wie in java.lang.Object. Benutzer definieren normalerweise keine Methoden wie Equals oder HashCode für ihre Typen, es sei denn, dies ist ausdrücklich erforderlich, da diese Methoden einen Typ nicht für die Verwendung als Zuordnungsschlüssel oder in einem Algorithmus qualifizieren, der Gleichheit erfordert.

(Equality in Go ist eine interessante Geschichte. Die Sprache gibt Ihrem Typ "==", wenn er bestimmte Anforderungen erfüllt (siehe https://golang.org/ref/spec#Logical_operators, suchen Sie nach "comparable"). Jeder Typ mit " ==" kann als Zuordnungsschlüssel dienen. Aber wenn Ihr Typ "==" nicht verdient, können Sie nichts schreiben, was ihn als Zuordnungsschlüssel funktionieren lässt.)

Da Methoden nicht allgegenwärtig sind und es keine einfache Möglichkeit gibt, Eigenschaften der integrierten Typen auszudrücken (z. B. mit welchen Operatoren sie arbeiten), habe ich vorgeschlagen, Code selbst als generischen Einschränkungsmechanismus zu verwenden. Siehe den Link in meinem Kommentar vom 18. April oben. Dieser Vorschlag hat seine Probleme, aber ein nettes Feature ist, dass generischer numerischer Code immer noch die üblichen Operatoren anstelle von umständlichen Methodenaufrufen verwenden könnte.

Die andere Möglichkeit besteht darin, Methoden zu Typen hinzuzufügen, denen sie fehlen. Sie können dies in der vorhandenen Sprache viel leichter tun als in Java:

Typ Int Int
func (i Int) Less(j Int) bool { return i < j }

Der Int-Typ „erbt“ alle Operatoren und andere Eigenschaften von int. Obwohl Sie zwischen den beiden umwandeln müssen, um Int und int zusammen zu verwenden, was ein Schmerz sein kann.

Gattungsmodelle könnten hier helfen. Aber sie müssten sehr einfach gehalten werden. Ich denke, @ianlancetaylor war zu eng in seiner Charakterisierung von Go als das Schreiben von mehr Code, weniger Typen. Das allgemeine Prinzip ist, dass Go Komplexität verabscheut. Wir schauen uns Java und C++ an und sind fest entschlossen, niemals dorthin zu gehen. (Nichts für ungut.)

Eine schnelle Idee für ein modellähnliches Feature wäre also: Lassen Sie den Benutzer Typen wie Int oben schreiben und erlauben Sie in generischen Instanziierungen "int mit Int", was bedeutet, dass Sie den Typ int verwenden, ihn aber wie Int behandeln. Dann gibt es kein offenkundiges Sprachkonstrukt namens model mit seinem Schlüsselwort Vererbungssemantik und so weiter. Ich verstehe Modelle nicht gut genug, um zu wissen, ob dies machbar ist, aber es ist mehr im Geiste von Go.

@jba Dem Prinzip der Vermeidung von Komplexität stimmen wir auf jeden Fall zu. "So einfach wie möglich, aber nicht einfacher." Aus diesen Gründen würde ich wahrscheinlich einige Genus-Features aus Go herauslassen, zumindest am Anfang.

Eines der netten Dinge am Genus-Ansatz ist, dass er eingebaute Typen reibungslos handhabt. Denken Sie daran, dass primitive Typen in Java keine Methoden haben und Genus dieses Verhalten erbt. Stattdessen behandelt Genus primitive Typen _als ob_ sie eine ziemlich große Sammlung von Methoden zum Zweck der Erfüllung von Beschränkungen hätten. Eine Hash-Tabelle erfordert, dass ihre Schlüssel gehasht und verglichen werden können, aber alle primitiven Typen erfüllen diese Einschränkung. Typ-Instanziierungen wie Map[int, boolean] sind also ohne weiteres Aufhebens vollkommen legal. Um dies zu erreichen, muss nicht zwischen zwei Arten von Ganzzahlen (int vs. Int) unterschieden werden. Wenn int jedoch nicht mit genügend Operationen für einige Anwendungen ausgestattet wäre, würden wir ein Modell verwenden, das fast genau wie die Verwendung von Int oben ist.

Erwähnenswert ist auch die Idee der "natürlichen Vorbilder" in Genus. Normalerweise müssen Sie kein Modell deklarieren, um einen generischen Typ zu verwenden: Wenn das Typargument die Einschränkung erfüllt, wird automatisch ein natürliches Modell generiert. Unserer Erfahrung nach ist dies der Regelfall; Das Deklarieren explizit benannter Modelle ist normalerweise nicht erforderlich. Wenn jedoch ein Modell benötigt wird – zum Beispiel, wenn Sie ints auf eine nicht standardmäßige Weise hashen möchten – dann ähnelt die Syntax dem, was Sie vorgeschlagen haben: Map[int with fancyHash, boolean] . Ich würde argumentieren, dass Genus in normalen Anwendungsfällen syntaktisch leicht ist, aber bei Bedarf mit Reserven ausgestattet ist.

@egonelbre Was Sie hier vorschlagen, sieht aus wie virtuelle Typen, die von Scala unterstützt werden. Es gibt ein ECOOP'97-Papier von Kresten Krab Thorup, "Genericity in Java with virtual types", das diese Richtung untersucht. Wir haben in unserer Arbeit auch Mechanismen für virtuelle Typen und virtuelle Klassen entwickelt ("J&: nested Intersection for Scalable Software Composition", OOPSLA'06).

Da wörtliche Initialisierungen in Go allgegenwärtig sind, musste ich mich fragen, wie ein Funktionsliteral aussehen würde. Ich vermute, dass der Code, um dies zu handhaben, größtenteils in Go generiert, repariert und umbenannt ist. Vielleicht wird es jemanden inspirieren :-)

// die (generische) Funktionstypdefinition
Typ Sum64 Funktion (X, Y) Float64 {
Rückgabe Float64(X) + Float64(Y)
}

// Eins instanziieren, positionell
ich := 42
var j uint = 86
Summe := &Summe64{i, j}

// einen instanziieren, nach benannten Parametertypen
sum := &Sum64{ X:int, Y:uint}

// jetzt benutze es...
Ergebnis := sum(i, j) // Ergebnis ist 128

Ians Vorschlag verlangt zu viel. Wir können unmöglich alle Funktionen auf einmal entwickeln, es wird viele Monate in einem unfertigen Zustand existieren.

In der Zwischenzeit kann das unvollendete Projekt nicht als offizielle Go-Sprache bezeichnet werden, bis es abgeschlossen ist, da dies zu einer Fragmentierung des Ökosystems führen könnte.

Die Frage ist also, wie man das plant.

Ein großer Teil des Projekts würde auch die Entwicklung des Referenzkorpus sein.
die eigentlichen generischen Sammlungen, Algorithmen und andere Dinge so zu entwickeln, dass wir uns alle einig sind, dass sie idiomatisch sind, während wir die neuen go 2.0-Funktionen verwenden

Eine mögliche Syntax?

// 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 , Syntax ist nicht der schwierige Teil dieses Problems. Tatsächlich ist es bei weitem das einfachste. Bitte beachten Sie die Diskussion und die verlinkten Dokumente oben.

@md2perpe Wir haben die Parametrisierung ganzer Pakete ("Module") als einen Weg zur internen Generizität diskutiert - es scheint ein Weg zu sein, den syntaktischen Overhead zu reduzieren. Aber es hat andere Probleme; zB ist nicht klar, wie man es mit Typen parametrisieren würde, die nicht auf Paketebene sind. Aber die Idee könnte es dennoch wert sein, im Detail untersucht zu werden.

Ich möchte eine Perspektive teilen: In einem Paralleluniversum waren alle Go-Funktionssignaturen immer darauf beschränkt, nur Schnittstellentypen zu erwähnen, und anstatt heute nach Generika zu verlangen, gibt es eine Möglichkeit, die mit Schnittstellenwerten verbundene Umleitung zu vermeiden. Überlegen Sie, wie Sie dieses Problem lösen würden (ohne die Sprache zu ändern). Ich habe einige Ideen.

@thwd Würde der Autor der Bibliothek also weiterhin Schnittstellen verwenden, jedoch ohne die heute erforderlichen Typumschaltungen und Typzusicherungen. Und würde der Benutzer der Bibliothek einfach konkrete Typen übergeben, als ob die Bibliothek die Typen so verwenden würde, wie sie sind ... und würde der Compiler dann die beiden in Einklang bringen? Und wenn es nicht sagen konnte, warum? (z. B. wurde der Modulo-Operator in der Bibliothek verwendet, aber der Benutzer hat ein Stück von etwas geliefert.

Bin ich in der Nähe? :-)

@mandolyte ja! Lassen Sie uns E-Mails austauschen, um diesen Thread nicht zu verschmutzen. Sie erreichen mich unter "me at thwd dot me". Jeder andere, der dies liest und interessiert sein könnte; Schicken Sie mir eine E-Mail und ich füge Sie dem Thread hinzu.

Es ist eine großartige Funktion für type system und collection library .
Eine mögliche Syntax:

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

Für interface

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

super type oder type implement :

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

Das obige aka in Java:

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

@leaxoy wie gesagt, die Syntax ist hier nicht der schwierige Teil. Siehe Diskussion oben.

Seien Sie sich nur bewusst, dass die Kosten für die Schnittstelle unglaublich hoch sind.

Bitte erläutern Sie, warum Sie denken, dass die Kosten für die Schnittstelle "unglaublich" sind.
groß.
Es sollte nicht schlechter sein als die nicht spezialisierten virtuellen Aufrufe von C++.

@minux Über die Leistungskosten kann ich nichts sagen, aber in Bezug auf die Codequalität. interface{} kann zur Kompilierzeit nicht verifiziert werden, Generika jedoch schon. Meiner Meinung nach ist dies in den meisten Fällen wichtiger als die Leistungsprobleme bei der Verwendung von interface{} .

@xoviat

Dies hat wirklich keinen Nachteil, da die dafür erforderliche Verarbeitung den Compiler nicht verlangsamt.

Es gibt (mindestens) zwei Nachteile.

Einer ist die erhöhte Arbeit für den Linker: Wenn die Spezialisierungen für zwei Typen zu demselben zugrunde liegenden Maschinencode führen, möchten wir nicht zwei Kopien dieses Codes kompilieren und verknüpfen.

Ein weiterer Grund ist, dass parametrisierte Pakete weniger aussagekräftig sind als parametrisierte Methoden. (Siehe die im ersten Kommentar verlinkten Vorschläge für Details.)

Ist Hypertyp eine gute Idee?

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

Ist Hypertyp eine gute Idee?

Was Sie hier beschreiben, ist nur Typparametrisierung ala C++ (dh Vorlagen). Es führt keine modulare Typprüfung durch, da es keine Möglichkeit gibt, anhand der gegebenen Informationen zu wissen, dass der Typ aType eine +-Operation hat. Die Parametrisierung eingeschränkter Typen wie in CLU, Haskell, Java, Genus ist die Lösung.

@ golang101 Ich habe einen detaillierten Vorschlag in diese Richtung. Ich schicke eine CL, um sie der Liste hinzuzufügen, aber es ist unwahrscheinlich, dass sie angenommen wird.

CL https://golang.org/cl/38731 erwähnt dieses Problem.

@andrewcmyers

Es führt keine modulare Typprüfung durch, da es keine Möglichkeit gibt, anhand der gegebenen Informationen zu wissen, dass der Typ aType eine +-Operation hat.

Sicher gibt es das. Diese Einschränkung ist in der Definition der Funktion implizit enthalten, und Einschränkungen dieser Form können an alle (transitiven) Kompilierzeit-Aufrufer von getAddFunc werden.

Die Einschränkung ist nicht Teil eines Go _type_ – das heißt, sie kann nicht im Typsystem des Laufzeitteils der Sprache codiert werden – aber das bedeutet nicht, dass sie nicht modular ausgewertet werden kann.

Meinen Vorschlag als 2016-09-compile-time-functions.md hinzugefügt.

Ich gehe nicht davon aus, dass es angenommen wird, aber es kann zumindest als interessanter Bezugspunkt dienen.

@bcmills Ich denke, dass Kompilierzeitfunktionen eine starke Idee sind, abgesehen von der Berücksichtigung von Generika. Zum Beispiel habe ich einen Sudoku-Löser geschrieben, der einen Popcount benötigt. Um das zu beschleunigen, habe ich die Popcounts für die verschiedenen möglichen Werte vorberechnet und als Go source gespeichert. Dies ist etwas, was man mit go:generate machen könnte. Aber wenn es eine Kompilierzeitfunktion gäbe, könnte diese Nachschlagetabelle genauso gut zur Kompilierzeit berechnet werden, sodass der maschinell generierte Code nicht an das Repo übergeben werden muss. Im Allgemeinen eignet sich jede Art von memoisierbarer mathematischer Funktion gut für vorgefertigte Nachschlagetabellen mit Kompilierzeitfunktionen.

Spekulativer könnte man zB auch eine Protobuf-Definition aus einer kanonischen Quelle herunterladen und diese zum Erstellen von Typen zur Kompilierzeit verwenden. Aber vielleicht ist das zu viel, um es zur Kompilierzeit tun zu dürfen?

Ich habe das Gefühl, dass Funktionen zur Kompilierzeit gleichzeitig zu leistungsfähig und zu schwach sind: Sie sind zu flexibel und können auf seltsame Weise Fehler verursachen / das Kompilieren verlangsamen, wie es C++-Vorlagen tun, aber andererseits sind sie zu statisch und schwer zu handhaben sich an Dinge wie erstklassige Funktionen anpassen.

Für den zweiten Teil sehe ich keine Möglichkeit, so etwas wie ein "Slice von Funktionen, die Slices eines bestimmten Typs verarbeiten und ein Element zurückgeben" oder in einer Ad-hoc-Syntax []func<T>([]T) T zu erstellen, die ist in praktisch jeder statisch typisierten funktionalen Sprache sehr einfach durchzuführen. Was wirklich benötigt wird, sind Werte , die parametrische Typen annehmen können, und nicht eine Codegenerierung auf Quellcodeebene.

@Bunsim

Für den zweiten Teil sehe ich keine Möglichkeit, so etwas wie ein "Slice von Funktionen zu erstellen, die Slices eines bestimmten Typs verarbeiten und ein Element zurückgeben".

Wenn Sie über einen einzelnen Typparameter sprechen, würde das in meinem Vorschlag geschrieben werden:

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

Wenn Sie über das Mischen von Typparametern und Wertparametern sprechen, nein, mein Vorschlag lässt dies nicht zu: Ein Teil des Sinns von Funktionen zur Kompilierzeit besteht darin, mit unverpackten Werten und der Art der Laufzeitparametrik arbeiten zu können Ich denke, Sie beschreiben ziemlich viel, was das Boxen von Werten erfordert.

Ja, aber meiner Meinung nach sollte so etwas, das Boxen erfordert, unter Beibehaltung der Typsicherheit erlaubt sein, vielleicht mit einer speziellen Syntax, die die "Boxedness" anzeigt. Ein großer Teil des Hinzufügens von "Generika" besteht wirklich darin, die Typunsicherheit von interface{} zu vermeiden, selbst wenn der Overhead von interface{} nicht vermeidbar ist. (Vielleicht nur bestimmte parametrische Typkonstrukte mit Zeiger- und Schnittstellentypen zulassen, die "bereits" geboxt sind? Javas Integer etc. geboxte Objekte sind keine ganz schlechte Idee, obwohl Segmente von Werttypen schwierig sind.)

Ich habe einfach das Gefühl, dass Funktionen zur Kompilierzeit sehr C++-ähnlich sind, und wäre extrem enttäuschend für Leute wie mich, die erwarten würden, dass Go2 ein modernes parametrisches Typsystem hat, das auf einer soliden Typtheorie basiert, und nicht auf einem Hack, der auf der Manipulation von geschriebenen Quellcodestücken basiert in einer Sprache ohne Generika.

@bcmills
Was Sie vorschlagen, wird nicht modular sein. Wenn Modul A Modul B verwendet, das Modul C verwendet, das Modul D verwendet, muss eine Änderung an der Verwendung eines Typparameters in D möglicherweise bis zurück zu A weitergegeben werden, selbst wenn der Implementierer von A keine Ahnung hat, dass D ist im System. Die lose Kopplung von Modulsystemen wird geschwächt, und Software wird spröder. Dies ist eines der Probleme mit C++-Vorlagen.

Wenn andererseits Typsignaturen die Anforderungen an Typparameter erfassen, wie in Sprachen wie CLU, ML, Haskell oder Genus, kann ein Modul ohne Zugriff auf die Interna von Modulen, von denen es abhängt, kompiliert werden.

@Bunsim

Ein großer Teil des Hinzufügens von "Generika" besteht wirklich darin, die Typunsicherheit von interface{} zu vermeiden, selbst wenn der Overhead von interface{} nicht vermeidbar ist.

"nicht vermeidbar" ist relativ. Beachten Sie, dass der Overhead des Boxens Punkt Nr. 3 in Russ' Post von 2009 ist (https://research.swtch.com/generic).

Erwarten Sie, dass Go2 ein modernes parametrisches Typsystem hat, das auf einer soliden Typtheorie basiert, und nicht auf einem Hack, der auf der Manipulation von Quellcodestücken basiert

Eine gute "Lauttypentheorie" ist beschreibend, nicht präskriptiv. Mein Vorschlag bezieht sich insbesondere auf den Lambda-Kalkül zweiter Ordnung (in Anlehnung an System F), wobei gotype für die Art type steht und das gesamte Typensystem erster Ordnung in das zweite hochgezogen wird -order ("compile-time") Typen.

Es steht auch im Zusammenhang mit der modalen Typentheoriearbeit von Davies, Pfenning et al. an der CMU. Als Hintergrundinformationen würde ich mit A Modal Analysis of Staged Computation and Modal Types as Staging Specifications for Run-time Code Generation beginnen.

Es stimmt, dass die meinem Vorschlag zugrunde liegende Typentheorie weniger formal spezifiziert ist als in der akademischen Literatur, aber das bedeutet nicht, dass sie nicht vorhanden ist.

@andrewcmyers

Wenn Modul A Modul B verwendet, das Modul C verwendet, das Modul D verwendet, muss eine Änderung an der Verwendung eines Typparameters in D möglicherweise bis zurück zu A weitergegeben werden, selbst wenn der Implementierer von A keine Ahnung hat, dass D ist im System.

Das gilt bereits heute für Go: Wenn Sie genau hinsehen, werden Sie feststellen, dass die vom Compiler für ein bestimmtes Go-Paket generierten Objektdateien Informationen zu den Teilen der transitiven Abhängigkeiten enthalten, die sich auf die exportierte API auswirken.

Die lose Kopplung von Modulsystemen wird geschwächt, und Software wird spröder.

Ich habe gehört, dass das gleiche Argument verwendet wurde, um für den Export interface -Typen statt konkreter Typen in Go-APIs einzutreten, und es stellt sich heraus, dass das Gegenteil häufiger vorkommt: vorzeitige Abstraktion überfordert die Typen und behindert die Erweiterung von APIs. (Für ein solches Beispiel siehe #19584.) Wenn Sie sich auf diese Argumentationslinie verlassen wollen, müssen Sie meiner Meinung nach einige konkrete Beispiele liefern.

Dies ist eines der Probleme mit C++-Vorlagen.

Aus meiner Sicht sind die Hauptprobleme mit C++-Vorlagen (in keiner bestimmten Reihenfolge):

• Übermäßige syntaktische Mehrdeutigkeit.
  A. Mehrdeutigkeit zwischen Typnamen und Wertnamen.
  B. Übermäßig breite Unterstützung für das Überladen von Operatoren, was zu einer geschwächten Fähigkeit führt, Einschränkungen aus der Operatornutzung abzuleiten.
• Übermäßige Abhängigkeit von der Überladungsauflösung für die Metaprogrammierung (oder äquivalent Ad-hoc-Entwicklung der Metaprogrammierungsunterstützung).
  A. Besonders in Bezug auf referenzreduzierende Regeln.
• Zu breite Anwendung des SFINAE-Prinzips, was zu sehr schwer zu verbreitenden Einschränkungen und viel zu vielen impliziten Bedingungen in Typdefinitionen führt, was zu sehr schwieriger Fehlerberichterstattung führt.
• Übermäßiger Einsatz von Token-Paste und textuellem Einfügen (der C-Präprozessor) anstelle von AST-Substitution und Kompilierungsartefakten höherer Ordnung (was glücklicherweise zumindest teilweise mit Modulen angegangen zu sein scheint).
• Mangel an guten Bootstrapping-Sprachen für C++-Compiler, was zu einer schlechten Fehlerberichterstattung in langlebigen Compiler-Linien (z. B. der GCC-Toolchain) führt.
• Die Verdoppelung (und manchmal Multiplikation) von Namen, die sich aus der Abbildung von Operatorsätzen auf unterschiedlich benannte "Konzepte" ergibt (anstatt die Operatoren selbst als grundlegende Einschränkungen zu behandeln).

Ich programmiere jetzt seit einem Jahrzehnt ab und zu in C++ und bin gerne bereit, die Mängel von C++ ausführlich zu diskutieren, aber die Tatsache, dass Programmabhängigkeiten transitiv sind, stand noch nie im Entferntesten ganz oben auf meiner Beschwerdeliste.

Andererseits müssen Sie eine Kette von O(N)-Abhängigkeiten aktualisieren, nur um eine einzelne Methode zu einem Typ in Modul A hinzuzufügen und in Modul D verwenden zu können? Das ist die Art von Problem, das mich regelmäßig ausbremst. Wo Parametrik und lose Kopplung kollidieren, werde ich jeden Tag Parametrik wählen.

Dennoch bin ich fest davon überzeugt, dass Metaprogrammierung und parametrischer Polymorphismus getrennt werden sollten, und die Verwirrung in C++ ist die Hauptursache dafür, warum C++-Templates lästig sind. Einfach ausgedrückt versucht C++, eine Typtheorie-Idee zu implementieren, indem es im Wesentlichen Makros auf Steroiden verwendet, was sehr problematisch ist, da Programmierer Templates gerne als echten parametrischen Polymorphismus betrachten und von unerwartetem Verhalten getroffen werden. Funktionen zur Kompilierzeit sind eine großartige Idee für die Metaprogrammierung und das Ersetzen des Hacks go generate , aber ich glaube nicht, dass dies die gesegnete Art der generischen Programmierung sein sollte.

"Echter" parametrischer Polymorphismus hilft bei der lockeren Kopplung und sollte nicht damit in Konflikt geraten. Es sollte auch eng mit dem Rest des Typensystems integriert sein; Zum Beispiel sollte es wahrscheinlich in das aktuelle Schnittstellensystem integriert werden, so dass viele Verwendungen von Schnittstellentypen in Dinge umgeschrieben werden könnten wie:

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

was Schnittstellen-Overhead vermeiden sollte (wie die Verwendung von Rust), obwohl es in diesem Fall nicht sehr nützlich ist.

Ein besseres Beispiel könnte das Paket sort sein, wo Sie so etwas haben könnten

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

wobei Comparable einfach eine gute alte Schnittstelle ist, die Typen implementieren können. Sort kann dann für ein Segment von Werttypen aufgerufen werden, die Comparable implementieren, ohne sie in Schnittstellentypen zu packen.

@bcmills Transitive Abhängigkeiten, die nicht durch das Typsystem eingeschränkt werden, sind meiner Ansicht nach der Kern einiger Ihrer Beschwerden über C ++. Transitive Abhängigkeiten sind kein so großes Problem, wenn Sie die Module A, B, C und D steuern. Im Allgemeinen entwickeln Sie Modul A und sind sich möglicherweise nur schwach bewusst, dass Modul D dort unten ist und umgekehrt der Entwickler von D möglicherweise A nicht bewusst ist. Wenn Modul D jetzt, ohne Änderungen an den in D sichtbaren Deklarationen vorzunehmen, beginnt, einen neuen Operator für einen Typparameter zu verwenden – oder diesen Typparameter lediglich als Typargument für ein neues Modul E mit seinem eigenen verwendet implizite Einschränkungen – diese Einschränkungen werden auf alle Clients durchsickern, die möglicherweise keine Typargumente verwenden, die die Einschränkungen erfüllen. Nichts sagt Entwickler D, dass sie es vermasseln. Tatsächlich haben Sie eine Art globalen Typrückschluss mit all den damit verbundenen Schwierigkeiten beim Debuggen.

Ich glaube, dass der Ansatz, den wir bei Genus [ PLDI'15 ] gewählt haben, viel besser ist. Typparameter haben explizite, aber leichtgewichtige Beschränkungen (ich verstehe Ihren Standpunkt bezüglich der Unterstützung von Betriebsbeschränkungen; CLU hat bereits 1977 gezeigt, wie man das richtig macht). Die Gattungstypprüfung ist vollständig modular. Allgemeiner Code kann entweder nur einmal kompiliert werden, um den Coderaum zu optimieren, oder für eine gute Leistung auf bestimmte Typargumente spezialisiert werden.

@andrewcmyers

Wenn Modul D jetzt, ohne Änderungen an den in D sichtbaren Deklarationen vorzunehmen, anfängt, einen neuen Operator für einen Typparameter zu verwenden, […] verwenden [Clients] möglicherweise keine Typargumente, die die Einschränkungen erfüllen. Nichts sagt Entwickler D, dass sie es vermasseln.

Sicher, aber das gilt bereits für viele implizite Einschränkungen in Go, unabhängig von generischen Programmiermechanismen.

Beispielsweise kann eine Funktion einen Parameter vom Typ Schnittstelle erhalten und ihre Methoden zunächst sequentiell aufrufen. Wenn sich diese Funktion später ändert, um diese Methoden gleichzeitig aufzurufen (durch das Spawnen zusätzlicher Goroutinen), wird die Einschränkung "muss für die gleichzeitige Verwendung sicher sein" nicht im Typsystem widergespiegelt.

In ähnlicher Weise legt das heutige Go-Typsystem keine Beschränkungen für die Lebensdauer von Variablen fest: Einige Implementierungen von io.Writer gehen fälschlicherweise davon aus, dass sie eine Referenz auf das übergebene Slice behalten und später daraus lesen können (z. B. indem sie den eigentlichen Schreibvorgang asynchron ausführen). in einer Hintergrund-Goroutine), aber das führt zu Datenrennen, wenn der Aufrufer von Write versucht, denselben Backing-Slice für ein nachfolgendes Write wiederzuverwenden.

Oder eine Funktion, die einen Typschalter verwendet, kann einen anderen Pfad einer Methode nehmen, die einem der Typen im Schalter hinzugefügt wird.

Oder eine Funktion, die nach einem bestimmten Fehlercode sucht, kann abbrechen, wenn die Funktion, die den Fehler generiert, die Art und Weise ändert, wie sie diese Bedingung meldet. (Siehe zum Beispiel https://github.com/golang/go/issues/19647.)

Oder eine Funktion, die nach einem bestimmten Fehlertyp sucht, kann abbrechen, wenn Wrapper um den Fehler hinzugefügt oder entfernt werden (wie im Standardpaket net in Go 1.5).

Oder die Pufferung auf einem in einer API offengelegten Kanal kann sich ändern, wodurch Deadlocks und/oder Races eingeführt werden.

...und so weiter.

Go ist in dieser Hinsicht nicht ungewöhnlich: Implizite Einschränkungen sind in realen Programmen allgegenwärtig.

Wenn Sie versuchen, alle relevanten Einschränkungen in expliziten Anmerkungen zu erfassen, gehen Sie am Ende in eine von zwei Richtungen.

In der einen Richtung bauen Sie ein komplexes, äußerst umfassendes System abhängiger Typen und Anmerkungen auf, und die Anmerkungen rekapitulieren am Ende einen wesentlichen Teil des Codes, den sie kommentieren. Wie Sie hoffentlich deutlich sehen können, entspricht diese Richtung überhaupt nicht dem Design der übrigen Go-Sprache: Go bevorzugt die Einfachheit der Spezifikation und die Prägnanz des Codes gegenüber einer umfassenden statischen Typisierung.

In der anderen Richtung würden die expliziten Anmerkungen nur eine Teilmenge der relevanten Einschränkungen für eine bestimmte API abdecken. Jetzt vermitteln die Anmerkungen ein falsches Sicherheitsgefühl: Der Code kann aufgrund von Änderungen an impliziten Einschränkungen immer noch brechen, aber das Vorhandensein expliziter Einschränkungen verleitet den Entwickler zu der Annahme, dass jede "typsichere" Änderung auch die Kompatibilität aufrechterhält.

Es ist mir nicht klar, warum diese Art von API-Stabilität durch explizite Quellcodeannotation erreicht werden muss: Die Art von API-Stabilität, die Sie beschreiben, kann auch (mit weniger Redundanz im Code) durch Quellcodeanalyse erreicht werden. Beispielsweise könnten Sie sich vorstellen, dass das api -Tool den Code analysiert und einen viel umfangreicheren Satz von Einschränkungen ausgibt, als im formalen Typsystem der Sprache ausgedrückt werden können, und dem guru -Tool die Fähigkeit, den berechneten Satz von Beschränkungen für jede gegebene API-Funktion, Methode oder Parameter abzufragen.

@bcmills Machst du das Perfekte nicht zum Feind des Guten? Ja, es gibt implizite Einschränkungen, die in einem Typsystem schwer zu erfassen sind. (Und ein gutes modulares Design vermeidet die Einführung solcher impliziter Einschränkungen, wenn dies möglich ist.) Es wäre großartig, eine allumfassende Analyse zu haben, die alle Eigenschaften, die Sie überprüfen möchten, statisch überprüfen kann – und Programmierern klare, nicht irreführende Erklärungen darüber liefert, wo sie sich befinden machen Fehler. Auch bei den jüngsten Fortschritten bei der automatischen Fehlerdiagnose und -lokalisierung halte ich nicht die Luft an. Zum einen können Analysetools nur den Code analysieren, den Sie ihnen geben. Entwickler haben nicht immer Zugriff auf den gesamten Code, der möglicherweise mit ihrem verknüpft ist.

Wo es also Einschränkungen gibt, die in einem Typsystem leicht zu erfassen sind, warum geben Sie Programmierern nicht die Möglichkeit, sie aufzuschreiben? Wir haben 40 Jahre Erfahrung in der Programmierung mit statisch eingeschränkten Typparametern. Dies ist eine einfache, intuitive statische Annotation, die sich auszahlt.

Sobald Sie anfangen, größere Software zu entwickeln, die Softwaremodule schichtet, möchten Sie sowieso Kommentare schreiben, die solche impliziten Einschränkungen erklären. Angenommen, es gibt eine gute, überprüfbare Möglichkeit, sie auszudrücken, warum lassen Sie den Compiler dann nicht auf den Witz ein, damit er Ihnen helfen kann?

Ich stelle fest, dass einige Ihrer Beispiele für andere implizite Einschränkungen die Fehlerbehandlung beinhalten. Ich denke, unsere einfache statische Überprüfung von Ausnahmen [ PLDI 2016 ] würde diese Beispiele ansprechen.

@andrewcmyers

Wo es also Einschränkungen gibt, die in einem Typsystem leicht zu erfassen sind, warum geben Sie Programmierern nicht die Möglichkeit, sie aufzuschreiben?
[…]
Sobald Sie anfangen, größere Software zu entwickeln, die Softwaremodule schichtet, möchten Sie sowieso Kommentare schreiben, die solche impliziten Einschränkungen erklären. Angenommen, es gibt eine gute, überprüfbare Möglichkeit, sie auszudrücken, warum lassen Sie den Compiler dann nicht auf den Witz ein, damit er Ihnen helfen kann?

Ich stimme diesem Punkt eigentlich vollkommen zu und verwende oft ein ähnliches Argument in Bezug auf die Speicherverwaltung. (Wenn Sie sowieso Invarianten zum Aliasing und zur Aufbewahrung von Daten dokumentieren müssen, warum erzwingen Sie diese Invarianten nicht zur Kompilierzeit?)

Aber ich würde dieses Argument noch einen Schritt weiterführen: Auch die Umkehrung gilt! Wenn Sie für eine Einschränkung _keinen_ Kommentar schreiben müssen (weil es im Kontext für die Menschen, die mit dem Code arbeiten, offensichtlich ist), warum sollten Sie diesen Kommentar für den Compiler schreiben müssen? Unabhängig von meinen persönlichen Vorlieben weist Gos Verwendung von Garbage-Collection und Nullwerten eindeutig auf eine Tendenz hin, "von Programmierern nicht zu verlangen, offensichtliche Invarianten anzugeben". Es mag der Fall sein, dass die Modellierung im Genus-Stil viele der Einschränkungen ausdrücken kann, die in Kommentaren ausgedrückt würden, aber wie schneidet sie ab, wenn es darum geht, die Einschränkungen zu beseitigen, die auch in Kommentaren aufgehoben würden?

Mir scheint, dass Modelle im Genus-Stil sowieso mehr als nur Kommentare sind: Sie ändern in einigen Fällen tatsächlich die Semantik des Codes, sie schränken ihn nicht nur ein. Jetzt hätten wir zwei verschiedene Mechanismen – Schnittstellen und Typmodelle – zum Parametrisieren von Verhaltensweisen. Das würde eine große Veränderung in der Go-Sprache darstellen: Wir haben im Laufe der Zeit einige Best Practices für Schnittstellen entdeckt (z. B. „Definieren von Schnittstellen auf der Verbraucherseite“), und es ist nicht einmal offensichtlich, dass sich diese Erfahrung auf ein so radikal anderes System übertragen würde Vernachlässigung der Go 1-Kompatibilität.

Darüber hinaus ist eine der herausragenden Eigenschaften von Go, dass seine Spezifikation an einem Nachmittag gelesen (und weitgehend verstanden) werden kann. Es ist für mich nicht offensichtlich, dass ein Beschränkungssystem im Genus-Stil zur Go-Sprache hinzugefügt werden könnte, ohne sie wesentlich zu verkomplizieren – ich wäre gespannt auf einen konkreten Vorschlag für Änderungen an der Spezifikation.

Hier ist ein interessanter Datenpunkt für "Metaprogrammierung". Es wäre schön, wenn bestimmte Typen in den Paketen sync und atomic – nämlich atomic.Value und sync.Map – CompareAndSwap -Methoden unterstützen würden, aber diese funktionieren nur für Typen, die zufällig vergleichbar sind. Der Rest der atomic.Value - und sync.Map -APIs bleibt ohne diese Methoden nützlich, also brauchen wir für diesen Anwendungsfall entweder so etwas wie SFINAE (oder andere Arten von bedingt definierten APIs) oder müssen fallen zurück zu einer komplexeren Hierarchie von Typen.

Ich möchte diese kreative Syntaxidee der Verwendung von Silben der Ureinwohner fallen lassen.

@bcmills Können Sie diese drei Punkte näher erläutern?

1. Mehrdeutigkeit zwischen Typnamen und Wertnamen.
2. Übermäßig breite Unterstützung für das Überladen von Operatoren
   3.Zu starke Abhängigkeit von der Überladungsauflösung für die Metaprogrammierung

@mahdix Sicher.

1. Mehrdeutigkeit zwischen Typnamen und Wertnamen.

Dieser Artikel gibt eine gute Einführung. Um ein C++-Programm zu parsen, müssen Sie wissen, welche Namen Typen und welche Werte sind. Wenn Sie ein auf Vorlagen basierendes C++-Programm parsen, stehen Ihnen diese Informationen für Mitglieder der Vorlagenparameter nicht zur Verfügung.

Ein ähnliches Problem tritt in Go für zusammengesetzte Literale auf, aber die Mehrdeutigkeit besteht eher zwischen Werten und Feldnamen als zwischen Werten und Typen. In diesem Go-Code:

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

ist a ein wörtlicher Feldname oder wird die Konstante a als Zuordnungsschlüssel oder Array-Index verwendet?

1. Übermäßig breite Unterstützung für das Überladen von Operatoren

Die argumentabhängige Suche ist ein guter Ausgangspunkt. Überladungen von Operatoren in C++ können als Methoden für den Empfängertyp oder als freie Funktionen in einem von mehreren Namespaces auftreten, und die Regeln zum Auflösen dieser Überladungen sind ziemlich komplex.

Es gibt viele Möglichkeiten, diese Komplexität zu vermeiden, aber die einfachste (wie Go es derzeit tut) besteht darin, das Überladen von Operatoren vollständig zu verbieten.

1. Übermäßige Abhängigkeit von der Überladungsauflösung für die Metaprogrammierung

Die <type_traits> -Bibliothek ist ein guter Ausgangspunkt. Schauen Sie sich die Implementierung in Ihrer freundlichen Nachbarschaft libc++ an, um zu sehen, wie die Auflösung von Überladungen ins Spiel kommt.

Wenn Go jemals Metaprogrammierung unterstützt (und selbst das ist sehr zweifelhaft), würde ich nicht erwarten, dass es die Auflösung von Überladungen als grundlegende Operation zum Schutz bedingter Definitionen beinhaltet.

@bcmills
Da ich C++ noch nie verwendet habe, könnten Sie etwas Licht ins Dunkel bringen, wo das Überladen von Operatoren durch die Implementierung vordefinierter „Schnittstellen“ in Bezug auf die Komplexität steht. Python und Kotlin sind Beispiele dafür.

Ich denke, dass ADL selbst ein großes Problem mit C++-Vorlagen ist, die größtenteils unerwähnt blieben, da sie den Compiler zwingen, die Auflösung aller Namen bis zur Instanziierung zu verzögern, und zu sehr subtilen Fehlern führen können, teilweise weil das "Ideal" und " faule" Compiler verhalten sich hier anders und der Standard lässt es zu. Die Tatsache, dass es das Überladen von Operatoren unterstützt, ist bei weitem nicht das Schlimmste daran.

Dieser Vorschlag basiert auf Templates, ein System zur Makroerweiterung wäre nicht genug? Ich spreche nicht von go generate oder Projekten wie gotemplate. Mir geht es eher um Folgendes:

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

Makro könnte die Boilerplate und die Verwendung von Reflektion reduzieren.

Ich denke, dass C++ ein gutes Beispiel dafür ist, dass Generics nicht auf Templates oder Makros basieren sollten. Besonders wenn man bedenkt, dass Go Dinge wie anonyme Funktionen hat, die zur Kompilierzeit wirklich nicht "instanziiert" werden können, außer als Optimierung.

@samadadi Sie können Ihren Standpunkt klar machen, ohne zu sagen, "was mit Ihnen nicht stimmt". Allerdings ist das Argument der Komplexität bereits mehrfach vorgebracht worden.

Go ist nicht die erste Sprache, die versucht, Einfachheit zu erreichen, indem sie die Unterstützung für parametrischen Polymorphismus (Generika) weglässt, obwohl diese Funktion in den letzten 40 Jahren immer wichtiger wurde – meiner Erfahrung nach ist es ein fester Bestandteil von Programmierkursen im zweiten Semester.

Das Problem, wenn das Feature nicht in der Sprache vorhanden ist, besteht darin, dass Programmierer am Ende auf noch schlimmere Problemumgehungen zurückgreifen. Zum Beispiel schreiben Go-Programmierer oft Codevorlagen, die makroerweitert werden, um den "echten" Code für verschiedene gewünschte Typen zu erzeugen. Aber die eigentliche Programmiersprache ist die, die Sie eingeben, nicht die, die der Compiler sieht. Diese Strategie bedeutet also effektiv, dass Sie eine (nicht mehr standardmäßige) Sprache verwenden, die all die Sprödigkeit und den aufgeblähten Code von C++-Vorlagen aufweist.

Wie auf https://blog.golang.org/toward-go2 erwähnt, müssen wir „Erfahrungsberichte“ bereitstellen, damit Bedarf und Gestaltungsziele ermittelt werden können. Könnten Sie sich ein paar Minuten Zeit nehmen und die von Ihnen beobachteten Makrofälle dokumentieren?

Bitte halten Sie diesen Fehler beim Thema und höflich. Und nochmal https://golang.org/wiki/NoMeToo. Bitte kommentieren Sie nur, wenn Sie einzigartige und konstruktive Informationen hinzufügen möchten.

@mandolyte Es ist sehr einfach, im Web detaillierte Erklärungen zu finden, die die Codegenerierung als (teilweisen) Ersatz für Generika befürworten:
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/

Offensichtlich gibt es viele Leute da draußen, die diesen Ansatz verfolgen.

@andrewcmyers , es gibt einige Einschränkungen sowie Einschränkungen bei der Verwendung der Codegenerierung ABER .
Im Allgemeinen - wenn Sie glauben, dass dieser Ansatz am besten / gut genug ist, denke ich, dass die Anstrengung, eine etwas ähnliche Generierung aus der Go-Toolkette heraus zu ermöglichen, ein Segen wäre.

• Die Compiler-Optimierung kann in diesem Fall eine Herausforderung sein, aber die Laufzeit wird konsistent sein, UND die Codewartung, die Benutzererfahrung (Einfachheit...), standardmäßige Best Practices und vereinheitlichte Codestandards können beibehalten werden.
  Darüber hinaus bleibt die gesamte Toolkette gleich, abgesehen von Debugging-Tools (Profiler, Step-Debugger usw.), die Codezeilen sehen, die nicht vom Entwickler geschrieben wurden, aber das ist ein bisschen so, als würde man während des Debuggens in ASM-Code einsteigen - nur Es ist ein lesbarer Code :) .

Nachteil - kein Präzedenzfall (den ich kenne) für diesen Ansatz innerhalb der Go-Tool-Kette.

Um es zusammenzufassen: Betrachten Sie die Codegenerierung als Teil des Build-Prozesses, sie sollte nicht zu kompliziert, ziemlich sicher, laufzeitoptimiert sein, kann Einfachheit und sehr kleine Änderungen in der Sprache beibehalten.

IMHO: Es ist ein leicht zu erreichender Kompromiss zu einem niedrigen Preis.

Um es klar zu sagen, ich halte die Generierung von Code im Makrostil, ob mit gen, cpp, gofmt -r oder anderen Makro-/Vorlagenwerkzeugen, nicht für eine gute Lösung des Generika-Problems, selbst wenn sie standardisiert ist. Es hat die gleichen Probleme wie C++-Templates: aufgeblähter Code, fehlende modulare Typprüfung und Schwierigkeiten beim Debuggen. Es wird schlimmer, wenn Sie beginnen, wie es natürlich ist, generischen Code in Bezug auf anderen generischen Code zu erstellen. Meiner Meinung nach sind die Vorteile begrenzt: Es würde das Leben für die Autoren des Go-Compilers relativ einfach machen und es produziert effizienten Code – es sei denn, es gibt einen Befehls-Cache-Druck, eine häufige Situation in moderner Software!

Ich denke, der Punkt war eher, dass die Codegenerierung als Ersatz verwendet wird
Generika, daher sollten Generika versuchen, die meisten dieser Anwendungsfälle zu lösen.

Am Mittwoch, 26. Juli 2017, 22:41 schrieb Andrew Myers, [email protected] :

Um es klar zu sagen, ich ziehe die Codegenerierung im Makrostil nicht in Betracht, unabhängig davon, ob sie durchgeführt wird
mit gen, cpp, gofmt -r oder anderen Makro-/Template-Tools, um gut zu sein
Lösung des Generika-Problems, auch wenn es standardisiert ist. Es hat das gleiche
Probleme als C++-Templates: aufgeblähter Code, fehlende modulare Typprüfung und
Schwierigkeiten beim Debuggen. Es wird schlimmer, wenn Sie beginnen, wie es natürlich ist, zu bauen
generischer Code in Bezug auf anderen generischen Code. Die Vorteile sind meiner Meinung nach
begrenzt: Es würde das Leben für die Autoren des Go-Compilers relativ einfach halten
und es produziert effizienten Code – es sei denn, es gibt einen Befehls-Cache
Druck, eine häufige Situation in moderner Software!

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment-318242016 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AT4HVb2SPMpe5dlEDUQeadIRKPaB74zoks5sR_jSgaJpZM4IG-xv
.

Zweifellos ist die Codegenerierung keine ECHTE Lösung, auch wenn sie mit etwas Sprachunterstützung verpackt ist, um das Erscheinungsbild als "Teil der Sprache" zu gestalten.

Mein Punkt war, dass es sehr kostengünstig war.

Übrigens, wenn Sie sich einige der Ersatzprodukte für die Codegenerierung ansehen, können Sie leicht erkennen, dass sie viel besser lesbar und schneller hätten sein können und einige falsche Konzepte hätten fehlen können (z. B. Iteration über Arrays von Zeigern vs. Werten), wenn die Sprache ihnen bessere Werkzeuge gegeben hätte dafür.

Und vielleicht ist das kurzfristig ein besserer Lösungsweg, der sich nicht wie ein Patch anfühlen würde:
Bevor Sie an die "beste Generika-Unterstützung denken, die auch idiomatisch sein wird" (ich glaube, einige der oben genannten Implementierungen würden Jahre dauern, um eine vollständige Integration zu erreichen), implementieren Sie einige Sätze von "in der Sprache" unterstützten Funktionen, die sowieso benötigt werden (wie eine eingebaute Strukturen Deep Copy) würde diese Codegenerierungslösung viel benutzerfreundlicher machen.

Nachdem ich die Generika-Vorschläge von @bcmills und @ianlancetaylor gelesen habe , habe ich folgende Beobachtungen gemacht:

Funktionen zur Kompilierzeit und erstklassige Typen

Ich mag die Idee der Auswertung zur Kompilierzeit, aber ich sehe keinen Vorteil darin, sie auf reine Funktionen zu beschränken. Dieser Vorschlag führt das eingebaute gotype ein, beschränkt seine Verwendung jedoch auf konstante Funktionen und alle Datentypen, die innerhalb des Funktionsbereichs definiert sind. Aus Sicht eines Bibliotheksbenutzers ist die Instanziierung auf Konstruktorfunktionen wie "New" beschränkt und führt zu Funktionssignaturen wie dieser:

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

Der Rückgabetyp kann hier nicht in einen Funktionstyp getrennt werden, da wir auf reine Funktionen beschränkt sind. Außerdem definiert die Signatur zwei neue "Typen" in der Signatur selbst (K und V), was bedeutet, dass wir zum Parsen eines einzelnen Parameters die gesamte Parameterliste parsen müssen. Dies ist für einen Compiler in Ordnung, aber ich frage mich, ob die öffentliche API eines Pakets komplexer wird.

Geben Sie Parameter in Go ein

Parametrisierte Typen ermöglichen die meisten Anwendungsfälle der generischen Programmierung, z. B. die Fähigkeit, generische Datenstrukturen und Operationen über verschiedene Datentypen zu definieren. Der Vorschlag listet erschöpfend Verbesserungen des Typprüfers auf, die erforderlich wären, um bessere Kompilierungsfehler, schnellere Kompilierungszeiten und kleinere Binärdateien zu erzeugen.

Unter dem Abschnitt "Type Checker" listet der Vorschlag auch einige nützliche Typbeschränkungen auf, um den Prozess zu beschleunigen, wie "Indexable", "Comparable", "Callable", "Composite" usw. Was ich nicht verstehe, ist Warum nicht dem Benutzer erlauben, seine eigenen Typbeschränkungen anzugeben? Das sagt der Vorschlag

Es gibt keine Einschränkungen, wie parametrisierte Typen in einer parametrisierten Funktion verwendet werden können.

Wenn jedoch an die Bezeichner mehr Einschränkungen gebunden wären, würde das nicht den Effekt haben, den Compiler zu unterstützen? Erwägen:

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.

Das Trennen von Typbeschränkungen von Typparametern und das Zulassen benutzerdefinierter Beschränkungen könnte auch die Lesbarkeit verbessern und generische Pakete leichter verständlich machen. Interessanterweise könnten die am Ende des Vorschlags aufgeführten Mängel bezüglich der Komplexität von Typableitungsregeln tatsächlich gemildert werden, wenn diese Regeln explizit vom Benutzer definiert werden.

@smasher164

Ich mag die Idee der Auswertung zur Kompilierzeit, aber ich sehe keinen Vorteil darin, sie auf reine Funktionen zu beschränken.

Der Vorteil ist, dass es eine getrennte Kompilierung ermöglicht. Wenn eine Funktion zur Kompilierzeit den globalen Status ändern kann, muss der Compiler diesen Status entweder verfügbar haben oder die Änderungen so protokollieren, dass der Linker sie zur Linkzeit sequenzieren kann. Wenn eine Funktion zur Kompilierzeit den lokalen Status ändern kann, benötigen wir eine Möglichkeit, um nachzuverfolgen, welcher Status lokal oder global ist. Beides erhöht die Komplexität, und es ist nicht offensichtlich, dass beides genügend Vorteile bieten würde, um dies auszugleichen.

@smasher164

Was ich nicht verstehe, ist, warum dem Benutzer nicht erlaubt wird, seine eigenen Typbeschränkungen anzugeben?

Die Typbeschränkungen in diesem Vorschlag entsprechen Operationen in der Syntax der Sprache. Dadurch wird die Oberfläche der neuen Funktionen reduziert: Es ist nicht erforderlich, zusätzliche Syntax für einschränkende Typen anzugeben, da alle syntaktischen Einschränkungen aus der Verwendung abgeleitet werden können.

Wenn an die Bezeichner mehr Einschränkungen gebunden wären, würde das nicht den Effekt haben, den Compiler zu unterstützen?

Die Sprache sollte für ihre Benutzer entworfen werden, nicht für die Compiler-Schreiber.

Es besteht keine Notwendigkeit, zusätzliche Syntax zum Einschränken von Typen anzugeben, da alle syntaktischen Einschränkungen aus der Verwendung abgeleitet werden können.

Dies ist der Weg, den C++ gegangen ist. Es bedarf einer globalen Programmanalyse, um die relevanten Nutzungen zu identifizieren. Code kann von Programmierern nicht modular begründet werden, und Fehlermeldungen sind ausführlich und unverständlich.

Es kann so einfach und leicht sein, die erforderlichen Operationen anzugeben. Siehe CLU (1977) für ein Beispiel.

@andrewcmyers

Es bedarf einer globalen Programmanalyse, um die relevanten Nutzungen zu identifizieren. Code kann von Programmierern nicht modular begründet werden,

Das verwendet eine bestimmte Definition von "modular", die meiner Meinung nach nicht so universell ist, wie Sie anzunehmen scheinen. Gemäß dem Vorschlag von 2013 hätte jede Funktion oder jeder Typ einen eindeutigen Satz von Einschränkungen, die von unten nach oben aus importierten Paketen abgeleitet werden, genau so, wie die Laufzeit (und Laufzeiteinschränkungen) von nichtparametrischen Funktionen von unten abgeleitet werden. heute aus Anrufketten auf.

Sie könnten vermutlich die abgeleiteten Einschränkungen mit guru oder einem ähnlichen Tool abfragen, und es könnte diese Abfragen mit lokalen Informationen aus den exportierten Paketmetadaten beantworten.

und Fehlermeldungen sind ausführlich und unverständlich.

Wir haben einige Beispiele (GCC und MSVC), die zeigen, dass naiv generierte Fehlermeldungen unverständlich sind. Ich denke, es ist weit hergeholt anzunehmen, dass Fehlermeldungen für implizite Einschränkungen an sich schlecht sind.

Ich denke, der größte Nachteil von abgeleiteten Einschränkungen ist, dass sie es einfach machen, einen Typ so zu verwenden, dass eine Einschränkung eingeführt wird, ohne sie vollständig zu verstehen. Im besten Fall bedeutet dies nur, dass Ihre Benutzer auf unerwartete Kompilierzeitfehler stoßen können, aber im schlimmsten Fall bedeutet dies, dass Sie das Paket für Verbraucher beschädigen können, indem Sie versehentlich eine neue Einschränkung einführen. Explizit spezifizierte Constraints würden dies vermeiden.

Ich persönlich bin auch nicht der Meinung, dass explizite Beschränkungen nicht mit dem bestehenden Go-Ansatz übereinstimmen, da Schnittstellen explizite Beschränkungen des Laufzeittyps sind, obwohl sie eine begrenzte Ausdruckskraft haben.

Wir haben einige Beispiele (GCC und MSVC), die zeigen, dass naiv generierte Fehlermeldungen unverständlich sind. Ich denke, es ist weit hergeholt anzunehmen, dass Fehlermeldungen für implizite Einschränkungen an sich schlecht sind.

Die Liste der Compiler, bei denen nicht-lokaler Typrückschluss - was Sie vorschlagen - zu schlechten Fehlermeldungen führt, ist um einiges länger. Es umfasst SML, OCaml und GHC, wo bereits viel Mühe in die Verbesserung ihrer Fehlermeldungen gesteckt wurde und wo zumindest eine explizite Modulstruktur hilft. Sie können es vielleicht besser machen, und wenn Sie mit dem von Ihnen vorgeschlagenen Schema einen Algorithmus für gute Fehlermeldungen finden, haben Sie eine schöne Veröffentlichung. Als Ausgangspunkt für diesen Algorithmus finden Sie möglicherweise unsere POPL 2014- und PLDI 2015-Papiere zur Fehlerlokalisierung nützlich. Sie sind mehr oder weniger Stand der Technik.

weil alle syntaktischen Beschränkungen aus der Verwendung gefolgert werden können.

Schränkt das nicht die Breite typüberprüfbarer generischer Programme ein? Beachten Sie beispielsweise, dass der Type-Params-Vorschlag keine „Iterable“-Einschränkung angibt. In der aktuellen Sprache würde dies entweder einem Slice oder einem Kanal entsprechen, aber ein zusammengesetzter Typ (z. B. eine verknüpfte Liste) würde diese Anforderungen nicht unbedingt erfüllen. Definieren einer Schnittstelle wie

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

hilft dem Fall der verknüpften Liste, aber jetzt müssen die eingebauten Slice- und Kanaltypen erweitert werden, um diese Schnittstelle zu erfüllen.

Eine Einschränkung, die besagt: „Ich akzeptiere die Menge aller Typen, die entweder Iterables, Slices oder Channels sind“, scheint eine Win-Win-Win-Situation für den Benutzer, den Paketautor und den Compiler-Implementierer zu sein. Der Punkt, den ich zu machen versuche, ist, dass Einschränkungen eine Obermenge von syntaktisch gültigen Programmen sind, und einige möglicherweise aus sprachlicher Sicht keinen Sinn ergeben, sondern nur aus API-Perspektive.

Die Sprache sollte für ihre Benutzer entworfen werden, nicht für die Compiler-Schreiber.

Ich stimme zu, aber vielleicht hätte ich es anders formulieren sollen. Eine verbesserte Compilereffizienz könnte ein Nebeneffekt von benutzerdefinierten Einschränkungen sein. Der Hauptvorteil wäre die Lesbarkeit, da der Benutzer ohnehin eine bessere Vorstellung von seinem API-Verhalten hat als der Compiler. Der Kompromiss hier ist, dass generische Programme etwas expliziter darüber sein müssten, was sie akzeptieren.

Was wäre wenn statt

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

Wir haben die Idee von "Schnittstellen" von "Einschränkungen" getrennt. Dann haben wir vielleicht

type T generic

type Iterable class {
    Next() T
}

wobei "Klasse" eine Typklasse im Haskell-Stil bedeutet, keine Klasse im Java-Stil.

"Typklassen" getrennt von "Schnittstellen" zu haben, könnte helfen, einige der Nicht-Orthogonalität der beiden Ideen aufzuklären. Dann könnte Sortable (sort.Interface ignorieren) etwa so aussehen:

type T generic

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

type Sortable class {
    Next() Comparable
}

Hier ist ein Feedback zum Abschnitt „Typklassen und -konzepte“ in Genus von @andrewcmyers und seiner Anwendbarkeit auf Go.

Dieser Abschnitt befasst sich mit den Einschränkungen von Typklassen und -konzepten und gibt an

Erstens muss die Einschränkungserfüllung eindeutig bezeugt werden

Ich bin mir nicht sicher, ob ich diese Einschränkung verstehe. Würde das Binden einer Einschränkung an separate Bezeichner nicht verhindern, dass sie für einen bestimmten Typ eindeutig ist? Es scheint mir, dass die "where" -Klausel in Genus im Wesentlichen einen Typ/eine Einschränkung aus einer gegebenen Einschränkung konstruiert, aber dies scheint analog zum Instanziieren einer Variablen von einem gegebenen Typ zu sein. Eine Einschränkung auf diese Weise ähnelt einer Art .

Hier ist eine dramatische Vereinfachung der Constraint-Definitionen, angepasst an 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.

Eine Kartendeklaration würde also folgendermaßen aussehen:

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

wo in Genus könnte es so aussehen:

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

und im bestehenden Type-Params-Vorschlag würde es so aussehen:

type Map[K,V] struct {
}

Ich denke, wir sind uns alle einig, dass das Zulassen von Beschränkungen zur Nutzung des bestehenden Typsystems sowohl Überschneidungen zwischen Funktionen der Sprache beseitigen als auch das Verständnis neuer erleichtern kann.

und zweitens definieren ihre Modelle, wie ein einzelner Typ angepasst wird, während in einer Sprache mit Subtypisierung jeder angepasste Typ im Allgemeinen alle seine Subtypen darstellt.

Diese Einschränkung scheint für Go weniger relevant zu sein, da die Sprache bereits über gute Konvertierungsregeln zwischen benannten/unbenannten Typen und überlappenden Schnittstellen verfügt.

Die angegebenen Beispiele schlagen Modelle als Lösung vor, was ein nützliches, aber nicht notwendiges Feature für Go zu sein scheint. Wenn eine Bibliothek beispielsweise erwartet, dass ein Typ http.Handler implementiert, und der Benutzer je nach Kontext unterschiedliche Verhaltensweisen wünscht, ist das Schreiben von Adaptern einfach:

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

Tatsächlich ist dies das, was die Standardbibliothek tut.

@smasher164

Erstens muss die Einschränkungserfüllung eindeutig bezeugt werden
Ich bin mir nicht sicher, ob ich diese Einschränkung verstehe. Würde das Binden einer Einschränkung an separate Bezeichner nicht verhindern, dass es für einen bestimmten Typ eindeutig ist?

Die Idee ist, dass Sie in Genus dieselbe Einschränkung mit demselben Typ auf mehr als eine Weise erfüllen können, anders als in Haskell. Wenn Sie beispielsweise ein HashSet[T] haben, können Sie HashSet[String] auf die übliche Weise in Hash-Strings schreiben, aber HashSet[String with CaseInsens] in Hash- und Vergleichsstrings mit CaseInsens -Modell, das Zeichenfolgen vermutlich ohne Berücksichtigung der Groß-/Kleinschreibung behandelt. Die Gattung unterscheidet tatsächlich diese beiden Typen; Dies könnte für Go übertrieben sein. Selbst wenn das Typsystem dies nicht verfolgt, scheint es dennoch wichtig zu sein, die von einem Typ bereitgestellten Standardoperationen überschreiben zu können.

kind Any interface{} // akzeptiert jeden Typ, der interface{} erfüllt.
type T Any // Einen beliebigen Typ deklarieren. Bindet es auch an einen Bezeichner.
kind Eq T == T // akzeptiert jeden Typ, für den Gleichheit definiert ist.
type Map[K Eq, V Any] struct { ...
}

Das moralische Äquivalent dazu in Genus wäre:

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] { ... }

In Familia würden wir einfach schreiben:

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

Bearbeiten: Dies zugunsten einer auf Reflexion basierenden Lösung zurückziehen, wie in # 4146 beschrieben. Eine auf Generika basierende Lösung, wie ich sie unten beschreibe, wächst linear in der Anzahl der Kompositionen. Während eine auf Reflexion basierende Lösung immer ein Leistungshandicap haben wird, kann sie sich zur Laufzeit selbst optimieren, so dass das Handicap unabhängig von der Anzahl der Kompositionen konstant ist.

Dies ist kein Vorschlag, sondern ein potenzieller Anwendungsfall, der beim Entwerfen eines Vorschlags berücksichtigt werden sollte.

Zwei Dinge sind heute im Go-Code üblich

• Wrapping eines Schnittstellenwerts, um zusätzliche Funktionalität bereitzustellen (Wrapping eines http.ResponseWriter für ein Framework)
• optionale Methoden haben, die manchmal Schnittstellenwerte haben (wie Temporary() bool auf net.Error )

Diese sind sowohl gut als auch nützlich, aber sie mischen sich nicht. Sobald Sie eine Schnittstelle umschlossen haben, haben Sie die Möglichkeit verloren, auf alle Methoden zuzugreifen, die nicht für den Umbruchtyp definiert sind. Das heißt, gegeben

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

Wenn Sie einen Fehler in diese Struktur einschließen, verbergen Sie alle zusätzlichen Methoden für den ursprünglichen Fehler.

Wenn Sie den Fehler nicht in die Struktur einschließen, können Sie den zusätzlichen Kontext nicht bereitstellen.

Nehmen wir an, dass Sie mit dem akzeptierten generischen Vorschlag etwas wie das Folgende definieren können (willkürliche Syntax, die ich absichtlich hässlich zu machen versuchte, damit sich niemand darauf konzentriert).

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)
}

Durch die Nutzung der Einbettung könnten wir jeden konkreten Typ einbetten, der die Fehlerschnittstelle erfüllt, und ihn sowohl umschließen als auch Zugriff auf seine anderen Methoden haben. Leider bringt uns das nur einen Teil des Weges dorthin.

Was wir hier wirklich brauchen, ist, einen beliebigen Wert der Fehlerschnittstelle zu nehmen und seinen dynamischen Typ einzubetten.

Dies wirft sofort zwei Bedenken auf

• der Typ müsste zur Laufzeit erstellt werden (wahrscheinlich ohnehin von Reflect benötigt)
• Die Typerstellung müsste in Panik geraten, wenn der Fehlerwert null ist

Wenn diese Sie nicht auf den Gedanken gebracht haben, brauchen Sie auch einen Mechanismus, um über die Schnittstelle zu ihrem dynamischen Typ zu "springen", entweder durch eine Anmerkung in der Liste der generischen Parameter, um zu sagen: "Immer den dynamischen Typ von Schnittstellenwerten instanziieren " oder durch eine magische Funktion, die nur während der Typinstanziierung aufgerufen werden kann, um die Schnittstelle zu entpacken, damit ihr Typ und Wert korrekt eingefügt werden können.

Ohne das instanziieren Sie nur MyError für den Fehlertyp selbst, nicht für den dynamischen Typ der Schnittstelle.

Nehmen wir an, wir haben eine magische unbox -Funktion, um die Informationen herauszuziehen und (irgendwie) anzuwenden:

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

Nehmen wir nun an, dass wir einen Nicht-Null-Fehler haben, err , dessen dynamischer Typ *net.DNSError ist. Dann das

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

würde true drucken. Aber wenn der dynamische Typ von err *os.PathError gewesen wäre, hätte er falsch ausgegeben.

Ich hoffe, die vorgeschlagene Semantik ist angesichts der stumpfen Syntax, die in der Demonstration verwendet wird, klar.

Ich hoffe auch, dass es einen besseren Weg gibt, dieses Problem mit weniger Mechanismus und Zeremonie zu lösen, aber ich denke, dass das oben Genannte funktionieren könnte.

@jimmyfrasche Wenn ich verstehe, was Sie wollen, ist es ein Wrapper-freier Anpassungsmechanismus. Sie möchten in der Lage sein, den Satz von Operationen zu erweitern, die ein Typ bietet, ohne ihn in ein anderes Objekt einzuhüllen, das das Original verbirgt. Dies ist eine Funktionalität, die Genus anbietet.

@andrewcmyers nein.

Struct's in Go ermöglichen das Einbetten. Wenn Sie ein Feld ohne Namen, aber mit einem Typ zu einer Struktur hinzufügen, bewirkt dies zwei Dinge: Es erstellt ein Feld mit demselben Namen wie der Typ und ermöglicht die transparente Weiterleitung an alle Methoden dieses Typs. Das klingt schrecklich nach Vererbung, ist es aber nicht. Wenn Sie einen Typ T hatten, der eine Methode Foo() hatte, dann sind die folgenden äquivalent

type S struct {
  T
}

und

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

(Wenn Foo aufgerufen wird, ist sein "this" immer vom Typ T).

Sie können Schnittstellen auch in Strukturen einbetten. Dies gibt der Struktur alle Methoden im Vertrag der Schnittstelle (obwohl Sie dem impliziten Feld einen dynamischen Wert zuweisen müssen oder es eine Panik mit dem Äquivalent einer Nullzeiger-Ausnahme verursacht)

Go verfügt über Schnittstellen, die einen Vertrag in Bezug auf die Methoden eines Typs definieren. Ein Wert eines beliebigen Typs, der den Vertrag erfüllt, kann in einen Wert dieser Schnittstelle geboxt werden. Ein Wert einer Schnittstelle ist ein Zeiger auf das interne Typmanifest (dynamischer Typ) und ein Zeiger auf einen Wert dieses dynamischen Typs (dynamischer Wert). Sie können Assertionen für einen Schnittstellenwert eingeben, um (a) den dynamischen Wert abzurufen, wenn Sie dessen Nicht-Schnittstellentyp bestätigen, oder (b) einen neuen Schnittstellenwert abzurufen, wenn Sie gegenüber einer anderen Schnittstelle bestätigen, dass der dynamische Wert ebenfalls erfüllt wird. Es ist üblich, letzteres zu verwenden, um ein Objekt zu testen, um zu sehen, ob es optionale Methoden unterstützt. Um ein früheres Beispiel wiederzuverwenden, haben einige Fehler eine "Temporary() bool"-Methode, damit Sie sehen können, ob ein Fehler temporär ist, mit:

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

Es ist auch üblich, einen Typ in einen anderen Typ einzuschließen, um zusätzliche Funktionen bereitzustellen. Dies funktioniert gut mit Nicht-Schnittstellentypen. Wenn Sie eine Schnittstelle umschließen, verstecken Sie jedoch auch die Methoden, die Sie nicht kennen, und Sie können sie nicht mit Assertionen vom Typ "Feature-Test" wiederherstellen: Der umschlossene Typ macht nur die erforderlichen Methoden der Schnittstelle verfügbar, selbst wenn er optionale Methoden hat . Erwägen:

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

type I interface {
  Foo()
}

type B struct {
  I
}

var i I = B{A{}}

Sie können Bar nicht auf i aufrufen oder sogar wissen, dass es existiert, es sei denn, Sie wissen, dass der dynamische Typ von i ein B ist, also können Sie es auspacken und in das I-Feld gelangen, um darauf eine Bestätigung einzugeben .

Dies verursacht echte Probleme, insbesondere im Umgang mit gängigen Schnittstellen wie Error oder Reader.

Wenn es eine Möglichkeit gäbe, den dynamischen Typ und Wert aus einer Schnittstelle zu entfernen (auf eine sichere, kontrollierte Weise), könnten Sie damit einen neuen Typ parametrisieren, das eingebettete Feld auf den Wert setzen und eine neue Schnittstelle zurückgeben. Dann erhalten Sie einen Wert, der die ursprüngliche Schnittstelle erfüllt, alle erweiterten Funktionen enthält, die Sie hinzufügen möchten, aber die restlichen Methoden des ursprünglichen dynamischen Typs sind immer noch vorhanden, um auf ihre Funktionen getestet zu werden.

@jimmyfrasche In der Tat. Genus erlaubt Ihnen, einen Typ zu verwenden, um einen "Schnittstellen"-Vertrag zu erfüllen, ohne ihn einzuschränken. Der Wert hat immer noch seinen ursprünglichen Typ und seine ursprünglichen Operationen. Außerdem kann das Programm angeben, welche Operationen der Typ verwenden soll, um den Vertrag zu erfüllen – standardmäßig sind dies die Operationen, die der Typ bereitstellt, aber das Programm kann neue bereitstellen, wenn der Typ nicht über die erforderlichen Operationen verfügt. Es kann auch die Operationen ersetzen, die der Typ verwenden würde.

@jimmyfrasche @andrewcmyers Für diesen Anwendungsfall siehe auch https://github.com/golang/go/issues/4146#issuecomment -318200547.

@jimmyfrasche Für mich klingt es so, als ob das Hauptproblem hier darin besteht, den dynamischen Typ/Wert einer Variablen zu erhalten. Abgesehen von der Einbettung wäre ein vereinfachtes Beispiel

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)
}

Der e zugewiesene Wert muss einen dynamischen (oder konkreten) Typ wie etwa *net.DNSError haben, der error implementiert. Hier sind ein paar Möglichkeiten, wie eine zukünftige Sprachänderung dieses Problem lösen könnte:

1. Haben Sie eine magische unbox -ähnliche Funktion, die den dynamischen Wert einer Variablen aufdeckt. Dies gilt für jeden Typ, der nicht konkret ist, zum Beispiel Unions.
2. Wenn die Sprachänderung Typvariablen unterstützt, stellen Sie eine Möglichkeit bereit, um den dynamischen Typ der Variablen abzurufen. Mit Typinformationen können wir die Funktion unbox selbst schreiben. Beispielsweise,

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

wrap kann genauso geschrieben werden wie zuvor oder als

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

1. Wenn die Sprachänderung Typbeschränkungen unterstützt, hier eine alternative Idee:

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,
  }
}

In diesem Beispiel akzeptieren wir einen Wert eines beliebigen Typs, der Fehler implementiert. Jeder Benutzer von wrap , der error erwartet, erhält einen. Der Typ von e innerhalb MyError ist jedoch derselbe wie der von err , der übergeben wird, was nicht auf einen Schnittstellentyp beschränkt ist. Wenn man das gleiche Verhalten wie 2 wollte,

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

Da es anscheinend sonst niemand gemacht hat, möchte ich auf die sehr offensichtlichen "Erfahrungsberichte" für Generika hinweisen, wie sie von https://blog.golang.org/toward-go2 gefordert werden.

Der erste ist der eingebaute Typ map :

m := make(map[string]string)

Der nächste ist der eingebaute Typ chan :

c := make(chan bool)

Schließlich ist die Standardbibliothek mit interface{} Alternativen gespickt, bei denen Generika sicherer funktionieren würden:

• 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)
• bevorstehende sync.Map (https://tip.golang.org/pkg/sync/#Map)
• atomic.Value (https://golang.org/pkg/sync/atomic/#Value)

Vielleicht fehlen mir noch andere. Der Punkt ist, dass ich bei jedem der oben genannten Bereiche davon ausgehen würde, dass Generika nützlich sind.

(Hinweis: Ich füge hier sort.Sort nicht hinzu, weil es ein hervorragendes Beispiel dafür ist, wie Schnittstellen anstelle von Generika verwendet werden können.)

http://www.yinwang.org/blog-cn/2014/04/18/golang
Ich denke, das Generikum ist wichtig. Andernfalls kann es nicht mit ähnlichen Typen umgehen. Manchmal kann die Schnittstelle das Problem nicht lösen.

Einfache Syntax und Typsystem sind die wichtigen Vorteile von Go. Wenn Sie Generika hinzufügen, wird die Sprache zu einem hässlichen Durcheinander wie Scala oder Haskell. Außerdem wird dieses Feature pseudoakademische Fanboys anziehen, die schließlich die Community-Werte von "Let's get this done" in "Lasst uns über CS-Theorie und Mathematik reden" verwandeln werden. Vermeiden Sie Generika, es ist ein Weg in den Abgrund.

@bxqgit bitte bleib höflich. Es ist nicht nötig, jemanden zu beleidigen.

Was die Zukunft bringen wird, werden wir sehen, aber ich weiß, dass ich zwar 98 % meiner Zeit keine Generika brauche, aber wann immer ich sie brauche, ich wünschte, ich könnte sie verwenden. Wie sie verwendet werden und wie sie falsch verwendet werden, ist eine andere Diskussion. Die Schulung der Benutzer sollte Teil des Prozesses sein.

@bxqgit
Es gibt Situationen, in denen Generika benötigt werden, wie generische Datenstrukturen (Trees, Stacks, Queues, ...) oder generische Funktionen (Map, Filter, Reduce, ...) und diese Dinge sind unvermeidlich, indem Schnittstellen anstelle von Generika verwendet werden Diese Situationen erhöhen nur die Komplexität sowohl für den Codeschreiber als auch für den Codeleser und wirken sich auch negativ auf die Codeeffizienz zur Laufzeit aus. Daher sollte es viel rationaler sein, Sprachgenerika hinzuzufügen, als zu versuchen, Schnittstellen zu verwenden und zu reflektieren, um komplex zu schreiben und ineffizienter Code.

@bxqgit Das Hinzufügen von Generika erhöht nicht unbedingt die Komplexität der Sprache, dies kann auch mit einfacher Syntax erreicht werden. Mit Generika fügen Sie eine Typbeschränkung für die variable Kompilierzeit hinzu, die bei Datenstrukturen sehr nützlich ist, wie @riwogo sagte.

Das aktuelle Schnittstellensystem in go ist sehr nützlich, ist aber sehr schlecht, wenn Sie beispielsweise eine allgemeine Implementierung von Listen benötigen, die bei Schnittstellen eine Ausführungszeit-Typbeschränkung benötigen. Wenn Sie jedoch Generika hinzufügen, kann der generische Typ ersetzt werden Kompilierzeit mit dem tatsächlichen Typ, wodurch die Einschränkung unnötig wird.

Denken Sie auch daran, dass die Leute dahinter die Sprache entwickeln, indem Sie das verwenden, was Sie "CS-Theorie und Mathematik" nennen, und auch die Leute sind, die "dies erledigen".

Denken Sie auch daran, dass die Leute dahinter die Sprache entwickeln, indem Sie das verwenden, was Sie "CS-Theorie und Mathematik" nennen, und auch die Leute sind, die "dies erledigen".

Persönlich sehe ich nicht viel CS-Theorie und Mathematik im Go-Sprachdesign. Es ist eine ziemlich primitive Sprache, was meiner Meinung nach gut ist. Auch die Leute, von denen Sie sprechen, haben beschlossen, Generika zu vermeiden, und haben die Dinge erledigt. Wenn es gut funktioniert, warum etwas ändern? Im Allgemeinen denke ich, dass es eine schlechte Praxis ist, die Syntax einer Sprache ständig weiterzuentwickeln und zu erweitern. Es erhöht nur die Komplexität, was zu einem Chaos von Haskell und Scala führt.

Die Vorlage ist kompliziert, aber Generics ist einfach

Sehen Sie sich die Funktionen SortInts, SortFloats, SortStrings im Sort-Paket an. Oder SearchInts, SearchFloats, SearchStrings. Oder die Methoden Len, Less und Swap von byName im Paket io/ioutil. Reines Boilerplate-Kopieren.

Die Kopier- und Anhängefunktionen existieren, weil sie Slices viel nützlicher machen. Generika würden bedeuten, dass diese Funktionen unnötig sind. Generics würden es ermöglichen, ähnliche Funktionen für Karten und Kanäle zu schreiben, ganz zu schweigen von benutzerdefinierten Datentypen. Zugegeben, Slices sind der wichtigste zusammengesetzte Datentyp, und deshalb wurden diese Funktionen benötigt, aber andere Datentypen sind immer noch nützlich.

Meine Stimme ist Nein zu generalisierten Anwendungsgenerika, Ja zu mehr integrierten generischen Funktionen wie append und copy , die auf mehreren Basistypen funktionieren. Vielleicht könnten sort und search für die Sammlungstypen hinzugefügt werden?

Für meine Anwendungen fehlt als einziger Typ ein ungeordneter Satz (https://github.com/golang/go/issues/7088). Ich möchte dies als integrierten Typ, damit er die generische Typisierung wie slice erhält map . Legen Sie die Arbeit in den Compiler (Benchmarking für jeden Basistyp und einen ausgewählten Satz von struct -Typen und anschließendes Optimieren für die beste Leistung) und halten Sie zusätzliche Anmerkungen aus dem Anwendungscode heraus.

smap eingebaut statt sync.Map auch bitte. Aus meiner Erfahrung ist die Verwendung interface{} für die Typsicherheit zur Laufzeit ein Designfehler. Die Typüberprüfung zur Kompilierzeit ist ein Hauptgrund, Go überhaupt zu verwenden.

@pciet

Aus meiner Erfahrung ist die Verwendung von Interface{} für Laufzeittypsicherheit ein Designfehler.

Können Sie einfach einen kleinen (typsicheren) Wrapper schreiben?
https://play.golang.org/p/tG6hd-j5yx

@pierrre Dieser Wrapper ist besser als ein reflect.TypeOf(item).AssignableTo(type) Scheck. Aber das Schreiben Ihres eigenen Typs mit map + sync.Mutex oder sync.RWMutex ist ohne die Typzusicherung, die sync.Map erfordert, genauso komplex.

Meine synchronisierte Kartenverwendung war für globale Karten von Mutexe mit einem var myMapLock = sync.RWMutex{} daneben, anstatt einen Typ zu erstellen. Das könnte sauberer sein. Ein generischer eingebauter Typ klingt für mich richtig, erfordert aber Arbeit, die ich nicht erledigen kann, und ich bevorzuge meinen Ansatz, anstatt den Typ zu bestätigen.

Ich vermute, dass die negative innere Reaktion auf Generika, die viele Go-Programmierer zu haben scheinen, darauf zurückzuführen ist, dass sie Generika hauptsächlich über C++-Vorlagen ausgesetzt waren. Das ist bedauerlich, weil C++ Generics vom ersten Tag an auf tragische Weise falsch verstanden hat und seitdem den Fehler verstärkt. Generics for Go könnten viel einfacher und weniger fehleranfällig sein.

Es wäre enttäuschend zu sehen, wie Go immer komplexer wird , indem eingebaute parametrisierte Typen hinzugefügt werden. Es wäre besser, nur die Sprachunterstützung hinzuzufügen, damit Programmierer ihre eigenen parametrisierten Typen schreiben können. Dann könnten die speziellen Typen einfach als Bibliotheken bereitgestellt werden, anstatt die Kernsprache zu überladen.

@andrewcmyers "Generika für Go könnten viel einfacher und weniger fehleranfällig sein." --- wie Generika in C#.

Es ist enttäuschend zu sehen, dass Go immer komplexer wird, indem eingebaute parametrisierte Typen hinzugefügt werden.

Trotz der Spekulationen in dieser Ausgabe halte ich dies für äußerst unwahrscheinlich.

Der Exponent des Komplexitätsmaßes parametrisierter Typen ist die Varianz.
Die Typen von Go (mit Ausnahme von Schnittstellen) sind unveränderlich, und das kann und sollte es auch sein
Regel gehalten.

Eine mechanische, Compiler-unterstützte "type copy-paster"-Generika-Implementierung
würde 99 % des Problems auf eine Art und Weise lösen, die Gos Basiswert entspricht
Prinzipien der Oberflächlichkeit und Nichtüberraschung.

Übrigens wurden diese und Dutzende anderer brauchbarer Ideen diskutiert
davor und einige mündeten sogar in gute, praktikable Ansätze. Bei diesem
Punkt, ich bin grenzwertig mit Stanniolhüten darüber, wie sie alle verschwunden sind
lautlos ins Leere.

Am 28. November 2017 um 23:54 Uhr schrieb „Andrew Myers“ [email protected] :

Ich vermute, dass die negative viszerale Reaktion auf Generika, die viele gehen
Programmierer scheinen entstanden zu sein, weil sie hauptsächlich Generika ausgesetzt waren
über C++-Templates. Das ist bedauerlich, weil C++ auf tragische Weise Generika bekommen hat
vom ersten Tag an falsch und hat den Fehler seitdem verstärkt. Generika für
Go könnte viel einfacher und weniger fehleranfällig sein.

Es ist enttäuschend zu sehen, wie Go durch Hinzufügen immer komplexer wird
eingebaute parametrisierte Typen. Es wäre besser, nur die Sprache hinzuzufügen
Unterstützung für Programmierer, ihre eigenen parametrisierten Typen zu schreiben. Dann ist die
spezielle Typen könnten einfach als Bibliotheken bereitgestellt werden, anstatt sie zu überladen
die Kernsprache.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment-347691444 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AJZ_jPsQd2qBbn9NI1wZeT-O2JpyraTMks5s7I81gaJpZM4IG-xv
.

Ja, Sie können Generika ohne Vorlagen haben. Vorlagen sind eine Form von fortgeschrittenem parametrischem Polymorphismus, hauptsächlich für Metaprogrammierungseinrichtungen.

@ianlancetaylor Rust ermöglicht es einem Programm, eine Eigenschaft T auf einem vorhandenen Typ Q zu implementieren, vorausgesetzt, dass ihre Kiste entweder T oder Q definiert.

Nur ein Gedanke: Ich frage mich, ob Simon Peyton Jones (ja, Haskell-Ruhm) und/oder die Rust-Entwickler vielleicht helfen können. Rust und Haskell haben wahrscheinlich die beiden fortschrittlichsten Typsysteme aller Produktionssprachen, und Go sollte von ihnen lernen.

Da ist auch Phillip Wadler , der an Generic Java arbeitete, was schließlich zu der Generics-Implementierung führte, die Java heute hat.

@tarcieri Ich denke nicht, dass die Generika von Java sehr gut sind, aber sie sind kampferprobt.

@DemiMarie Glücklicherweise hat Andrew Myers hier mitgeholfen.

Aufgrund meiner persönlichen Erfahrung denke ich, dass Menschen, die sich gut mit verschiedenen Sprachen und verschiedenen Schriftsystemen auskennen, bei der Prüfung von Ideen sehr hilfreich sein können. Aber um die Ideen überhaupt zu produzieren, brauchen wir Leute, die mit Go sehr vertraut sind, wie es heute funktioniert und wie es in Zukunft vernünftig funktionieren kann. Go ist unter anderem als einfache Sprache konzipiert. Das Importieren von Ideen aus Sprachen wie Haskell oder Rust, die wesentlich komplizierter sind als Go, wird wahrscheinlich nicht gut passen. Und im Allgemeinen sind Ideen von Leuten, die nicht bereits eine angemessene Menge an Go-Code geschrieben haben, wahrscheinlich nicht gut geeignet; nicht, dass die Ideen als solche schlecht wären, nur, dass sie nicht gut zum Rest der Sprache passen würden.

Es ist beispielsweise wichtig zu verstehen, dass Go bereits teilweise Unterstützung für generische Programmierung mit Schnittstellentypen und bereits (fast) vollständige Unterstützung mit dem Reflect-Paket bietet. Während diese beiden Ansätze zur generischen Programmierung aus verschiedenen Gründen unbefriedigend sind, muss jeder Vorschlag für Generika in Go gut mit ihnen interagieren und gleichzeitig ihre Mängel ansprechen.

Tatsächlich habe ich, während ich hier bin, vor einiger Zeit über generische Programmierung mit Schnittstellen nachgedacht und drei Gründe gefunden, warum sie nicht zufriedenstellend ist.

1. Schnittstellen erfordern, dass alle Operationen als Methoden ausgedrückt werden. Das macht es mühsam, eine Schnittstelle für eingebaute Typen wie Kanaltypen zu schreiben. Alle Kanaltypen unterstützen den <- -Operator für Sende- und Empfangsoperationen, und es ist einfach genug, eine Schnittstelle mit den Methoden Send und Receive zu schreiben, aber um einen Kanalwert zuzuweisen Für diesen Schnittstellentyp müssen Sie die Methoden Boilerplate Send und Receive schreiben. Diese Boilerplate-Methoden sehen für jeden Kanaltyp genau gleich aus, was mühsam ist.

2. Schnittstellen werden dynamisch typisiert, sodass Fehler, die verschiedene statisch typisierte Werte kombinieren, nur zur Laufzeit abgefangen werden, nicht zur Kompilierzeit. Beispielsweise erfordert eine Merge -Funktion, die zwei Kanäle mit ihren Methoden Send und Receive zu einem einzigen Kanal zusammenführt, dass die beiden Kanäle Elemente desselben Typs haben müssen, aber das Die Überprüfung kann nur zur Laufzeit durchgeführt werden.

3. Schnittstellen sind immer eingerahmt. Beispielsweise gibt es keine Möglichkeit, Schnittstellen zu verwenden, um ein Paar anderer Typen zu aggregieren, ohne diese anderen Typen in Schnittstellenwerte einzufügen, was zusätzliche Speicherzuweisungen und Zeigerverfolgung erfordert.

Auf Generika-Vorschläge für Go freue ich mich über Kibitz. Vielleicht auch von Interesse ist die in letzter Zeit zunehmende Forschung zu Generika bei Cornell, die anscheinend relevant für das ist, was mit Go gemacht werden könnte:

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)

Beim Benchmarking von Map vs. Slice für einen ungeordneten Set-Typ habe ich separate Unit-Tests für jeden geschrieben, aber mit Interface-Typen kann ich diese beiden Testlisten zu einer kombinieren:

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
}

Entfernen eines Elements testen:

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)
        }
    }
}

Auf diese Weise kann ich meine zuvor getrennten Fälle problemlos zu einem Teil von Fällen zusammenfügen:

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}},
        },
    },
}

Für jeden konkreten Typ musste ich die Schnittstellenmethoden definieren. Beispielsweise:

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

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

Diese generischen Tests könnten eine vorgeschlagene Typprüfung zur Kompilierzeit verwenden:

type Item generic {
    Equal(Item) bool
}

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

Quelle: https://github.com/pciet/pathsetbenchmark

Wenn man darüber nachdenkt, scheint es nicht so, als wäre eine Typüberprüfung zur Kompilierzeit für einen solchen Test möglich, da Sie das Programm ausführen müssten, um zu wissen, ob ein Typ an die entsprechende Schnittstellenmethode übergeben wird.

Was ist also mit einem "generischen" Typ, der eine Schnittstelle ist und bei der der Compiler bei konkreter Verwendung eine unsichtbare Typzusicherung hinzugefügt hat?

@andrewcmyers Das "Familia"-Papier war interessant (und weit über meinem Kopf). Ein Schlüsselbegriff war die Vererbung. Wie würden sich die Konzepte für eine Sprache wie Go ändern, die auf Komposition statt Vererbung setzt?

Danke. Der Vererbungsteil gilt nicht für Go – wenn Sie nur an Generika für Go interessiert sind, können Sie nach Abschnitt 4 des Papiers aufhören zu lesen. Das Wichtigste an diesem Artikel, der für Go relevant ist, ist, dass er zeigt, wie Schnittstellen verwendet werden, sowohl in der Art und Weise, wie sie jetzt für Go verwendet werden, als auch als Einschränkungen für Typen für generische Abstraktionen. Das bedeutet, dass Sie die Leistungsfähigkeit von Haskell-Klassen erhalten, ohne der Sprache ein völlig neues Konstrukt hinzuzufügen.

@andrewcmyers Kannst du ein Beispiel geben, wie das in Go aussehen würde?

Das Wichtigste an diesem Artikel, der für Go relevant ist, ist, dass er zeigt, wie Schnittstellen verwendet werden, sowohl in der Art und Weise, wie sie jetzt für Go verwendet werden, als auch als Einschränkungen für Typen für generische Abstraktionen.

Mein Verständnis ist, dass die Go-Schnittstelle eine Einschränkung für einen Typ definiert (z. B. "dieser Typ kann mit der 'type Comparable interface' auf Gleichheit verglichen werden, weil er eine Eq-Methode erfüllt"). Ich bin mir nicht sicher, ob ich verstehe, was Sie mit einer Typbeschränkung meinen.

Ich bin mit Haskell nicht vertraut, aber wenn ich einen kurzen Überblick lese, vermute ich, dass Typen, die zu einer Go-Schnittstelle passen, in diese Typklasse passen würden. Können Sie erklären, was bei Klassen vom Typ Haskell anders ist?

Ein konkreter Vergleich zwischen Familia und Go wäre interessant. Danke, dass Sie Ihr Papier geteilt haben.

Go-Schnittstellen können so angesehen werden, dass sie eine Einschränkung für Typen durch strukturelle Subtypisierung beschreiben. Diese Typbeschränkung ist jedoch so wie sie ist nicht aussagekräftig genug, um die Beschränkungen zu erfassen, die Sie für die generische Programmierung wünschen. Beispielsweise können Sie die Typbeschränkung mit dem Namen Eq im Familia-Papier nicht ausdrücken.

Einige Gedanken zur Motivation für allgemeinere Programmiermöglichkeiten in Go:

Es gibt also meine generische Testliste, bei der der Sprache eigentlich nichts hinzugefügt werden muss. Meiner Meinung nach erfüllt der von mir vorgeschlagene generische Typ nicht das Go-Ziel des einfachen Verständnisses, er hat nicht viel mit dem allgemein akzeptierten Programmierbegriff zu tun, und die Typzusicherung dort zu machen, war nicht hässlich, da eine Panik bei Fehlern ist fein. Ich bin mit den generischen Programmiermöglichkeiten von Go bereits für meine Bedürfnisse zufrieden.

Aber sync.Map ist ein anderer Anwendungsfall. In der Standardbibliothek besteht ein Bedarf für eine ausgereifte generische synchronisierte Zuordnungsimplementierung, die über eine Struktur mit einer Zuordnung und einem Mutex hinausgeht. Für die Typbehandlung können wir ihn mit einem anderen Typ umschließen, der einen Nicht-Interface{}-Typ festlegt und eine Typzusicherung durchführt, oder wir können intern eine Reflexionsprüfung hinzufügen, sodass Elemente, die dem ersten folgen, demselben Typ entsprechen müssen. Beide haben Laufzeitprüfungen, das Wrapping erfordert das Neuschreiben jeder Methode für jeden Verwendungstyp, aber es fügt eine Kompilierzeit-Typprüfung für die Eingabe hinzu und verbirgt die Ausgabetyp-Assertion, und mit der internen Prüfung müssen wir trotzdem eine Ausgabetyp-Assertion durchführen. In beiden Fällen führen wir Schnittstellenkonvertierungen durch, ohne dass Schnittstellen tatsächlich verwendet werden. interface{} ist ein Hack der Sprache und wird neuen Go-Programmierern nicht klar sein. Obwohl json.Marshal meiner Meinung nach ein gutes Design ist (einschließlich der hässlichen, aber sinnvollen Struktur-Tags).

Da sich sync.Map in der Standardbibliothek befindet, möchte ich hinzufügen, dass die Implementierung idealerweise für die gemessenen Anwendungsfälle ausgetauscht werden sollte, in denen die einfache Struktur leistungsfähiger ist. Die nicht synchronisierte Karte ist eine häufige frühe Falle bei der gleichzeitigen Go-Programmierung, und eine Standardbibliothekskorrektur sollte einfach funktionieren.

Die reguläre Karte hat nur eine Typüberprüfung zur Kompilierzeit und benötigt keines dieser Gerüste. Ich argumentiere, dass sync.Map die gleiche sein sollte oder nicht in der Standardbibliothek für Go 2 sein sollte.

Ich schlug vor, sync.Map zur Liste der integrierten Typen hinzuzufügen und dasselbe für zukünftige ähnliche Anforderungen zu tun. Aber mein Verständnis ist, Go-Programmierern eine Möglichkeit zu geben, dies zu tun, ohne am Compiler arbeiten und den Open-Source-Akzeptanzhandschuh durchlaufen zu müssen, ist die Idee hinter dieser Diskussion. Meiner Ansicht nach ist das Fixieren von sync.Map ein echter Fall, der teilweise definiert, was dieser Generika-Vorschlag sein sollte.

Wenn Sie sync.Map als integrierte Funktion hinzufügen, wie weit gehen Sie dann? Haben Sie einen Sonderfall für jeden Container?
sync.Map ist nicht der einzige Container und einige sind für einige Fälle besser als andere.

@Azareal : @chowey listete diese im August auf:

Schließlich ist die Standardbibliothek gespickt mit Interface{}-Alternativen, bei denen Generika sicherer funktionieren würden:

• 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)
• kommende sync.Map (https://tip.golang.org/pkg/sync/#Map)
• atomar.Wert (https://golang.org/pkg/sync/atomic/#Value)

Vielleicht fehlen mir noch andere. Der Punkt ist, dass ich bei jedem der oben genannten Bereiche davon ausgehen würde, dass Generika nützlich sind.

Und ich möchte die ungeordnete Menge für Typen, die auf Gleichheit verglichen werden können.

Ich möchte viel Arbeit in eine variable Implementierung in der Laufzeit für jeden Typ stecken, der auf Benchmarking basiert, damit normalerweise die bestmögliche Implementierung verwendet wird.

Ich frage mich, ob es vernünftige alternative Implementierungen mit Go 1 gibt, die das gleiche Ziel für diese Standardbibliothekstypen ohne Schnittstelle {} und ohne Generika erreichen.

Golang-Schnittstellen und Klassen vom Typ Haskell überwinden zwei Dinge (die sehr großartig sind!):

1.) (Type Constraint) Sie gruppieren verschiedene Typen mit einem Tag, dem Schnittstellennamen
2.) (Dispatch) Sie bieten an, für jeden Typ für einen bestimmten Satz von Funktionen über die Schnittstellenimplementierung unterschiedlich zu versenden

Aber,

1.) Manchmal möchten Sie nur anonyme Gruppen wie eine Gruppe von int, float64 und string. Wie sollten Sie eine solche Schnittstelle NumericandString nennen?

2.) Sehr oft möchte man nicht für jeden Interface-Typ unterschiedlich dispatchieren, sondern nur eine Methode für alle aufgelisteten Interface-Typen bereitstellen (evtl. mit Default-Methoden von Interfaces möglich)

3.) Sehr oft möchte man nicht alle möglichen Typen für eine Gruppe aufzählen. Stattdessen gehen Sie den faulen Weg und sagen, ich möchte, dass alle Typen T ein Interface A implementieren, und der Compiler sucht dann nach allen Typen in allen Quelldateien, die Sie bearbeiten, und in allen Bibliotheken, die Sie verwenden, um die entsprechenden Funktionen zur Kompilierzeit zu generieren.

Obwohl der letzte Punkt in go über Schnittstellenpolymorphismus möglich ist, hat er den Nachteil, dass es sich um einen Laufzeitpolymorphismus handelt, der Umwandlungen beinhaltet, und wie Sie die Parametereingabe einer Funktion so einschränken, dass sie Typen enthält, die mehr als eine Schnittstelle oder eine von vielen Schnittstellen implementieren. Der Weg ist, neue Schnittstellen einzuführen, die andere Schnittstellen erweitern (durch Verschachtelung von Schnittstellen), um etwas Ähnliches zu erreichen, aber nicht mit Best Practice.

Übrigens.
Ich gebe diejenigen zu, die sagen, dass go bereits Polymorphismus hat und genau deshalb ist go keine einfache Sprache mehr wie C. Es ist eine Systemprogrammiersprache auf hohem Niveau. Warum also nicht die Polymorphismus-Angebote erweitern?

Hier ist eine Bibliothek, die ich heute für generische ungeordnete Set-Typen gestartet habe: https://github.com/pciet/unordered

Dies enthält Dokumentations- und Testbeispiele, die das Typ-Wrapper-Muster (danke @pierrre) für Typsicherheit zur Kompilierungszeit und auch die Reflexionsprüfung für Typsicherheit zur Laufzeit enthalten.

Welche Bedürfnisse gibt es für Generika? Meine negative Einstellung gegenüber generischen Typen von Standardbibliotheken konzentrierte sich früher auf die Verwendung von interface{}; Meine Beschwerde könnte mit einem paketspezifischen Typ für interface{} (wie type Item interface{} in pciet/unordered) gelöst werden, der die beabsichtigten nicht ausdrückbaren Einschränkungen dokumentiert.

Ich sehe keine Notwendigkeit für eine zusätzliche Sprachfunktion, wenn uns jetzt nur die Dokumentation dorthin bringen könnte. Es gibt bereits große Mengen an kampferprobtem Code in der Standardbibliothek, die generische Funktionen bietet (siehe https://github.com/golang/go/issues/23077).

Ihr Codetyp wird zur Laufzeit überprüft (und aus dieser Perspektive ist es in keiner Weise besser als nur interface{} , wenn nicht sogar schlechter). Mit Generika hätten Sie die Sammlungstypen mit Typprüfungen zur Kompilierzeit haben können.

@zerkms -Laufzeitprüfungen können durch Setzen von asserting = false (das würde nicht in die Standardbibliothek gehen) abgeschaltet werden, es gibt ein Verwendungsmuster für Prüfungen zur Kompilierzeit, und eine Typprüfung betrachtet ohnehin nur die Schnittstellenstruktur (using Schnittstelle verursacht mehr Aufwand als die Typprüfung). Wenn die Schnittstelle nicht funktioniert, müssen Sie Ihren eigenen Typ schreiben.

Sie sagen, dass generischer Code mit maximaler Leistung ein Schlüsselbedürfnis ist. Es war nicht für meine Anwendungsfälle, aber vielleicht könnte die Standardbibliothek schneller werden, und vielleicht brauchen andere so etwas.

Laufzeitprüfungen können durch Setzen von asserting = false abgeschaltet werden

dann garantiert nichts die Richtigkeit

Sie sagen, dass generischer Code mit maximaler Leistung ein Schlüsselbedürfnis ist.

Das habe ich nicht gesagt. Typensicherheit wäre sehr viel. Ihre Lösung ist immer noch interface{} -infiziert.

aber vielleicht könnte die Standardbibliothek schneller werden, und vielleicht brauchen andere so etwas.

kann sein, wenn das Kernentwicklungsteam bereit ist, alles, was ich brauche, bei Bedarf und schnell zu implementieren.

@pciet

Ich sehe keine Notwendigkeit für eine zusätzliche Sprachfunktion, wenn uns jetzt nur die Dokumentation dorthin bringen könnte.

Sie sagen das, haben aber kein Problem damit, die generischen Sprachfeatures in Form von Slices und der Make-Funktion zu verwenden.

Ich sehe keine Notwendigkeit für eine zusätzliche Sprachfunktion, wenn uns jetzt nur die Dokumentation dorthin bringen könnte.

Warum sollte man sich dann die Mühe machen, eine statisch typisierte Sprache zu verwenden? Sie können eine dynamisch typisierte Sprache wie Python verwenden und sich auf die Dokumentation verlassen, um sicherzustellen, dass die richtigen Datentypen an Ihre API gesendet werden.

Ich denke, einer der Vorteile von Go ist die Möglichkeit, einige Einschränkungen durch den Compiler durchzusetzen, um zukünftige Fehler zu verhindern. Diese Einrichtungen können (mit Generika-Unterstützung) erweitert werden, um einige andere Einschränkungen durchzusetzen, um weitere Fehler in der Zukunft zu verhindern.

Sie sagen das, haben aber kein Problem damit, die generischen Sprachfeatures in Form von Slices und der Make-Funktion zu verwenden.

Ich sage, die bestehenden Funktionen bringen uns zu einem ausgewogenen Punkt, der generische Programmierlösungen hat, und es sollte starke, echte Gründe geben, vom System des Typs Go 1 zu wechseln. Nicht, wie eine Änderung die Sprache verbessern würde, sondern mit welchen Problemen die Leute jetzt konfrontiert sind, wie z.

Warum sollte man sich dann die Mühe machen, eine statisch typisierte Sprache zu verwenden? Sie können eine dynamisch typisierte Sprache wie Python verwenden und sich auf die Dokumentation verlassen, um sicherzustellen, dass die richtigen Datentypen an Ihre API gesendet werden.

Ich habe Vorschläge gehört, Systeme in Python zu schreiben, anstatt statisch typisierte Sprachen und Organisationen zu verwenden.

Die meisten Go-Programmierer, die die Standardbibliothek verwenden, verwenden Typen, die ohne Dokumentation oder ohne Blick auf die Implementierung nicht vollständig beschrieben werden können. Typen mit parametrischen Untertypen oder allgemeine Typen mit angewendeten Einschränkungen beheben nur eine Teilmenge dieser Fälle programmgesteuert und würden viel Arbeit erzeugen, die bereits in der Standardbibliothek erledigt ist.

Im Vorschlag für Summentypen habe ich eine Build-Funktion für den Schnittstellentyp-Schalter vorgeschlagen, bei der eine Schnittstellenverwendung in einer Funktion oder Methode einen Build-Fehler ausgibt, wenn ein möglicher Wert, der der Schnittstelle zugewiesen ist, nicht mit einem enthaltenen Schnittstellentyp-Schalter übereinstimmt.

Eine Funktion/Methode, die eine Schnittstelle verwendet, könnte einige Typen beim Erstellen ablehnen, da sie keinen Standardfall und keinen Fall für den Typ hat. Dies scheint eine vernünftige generische Programmierergänzung zu sein, wenn die Funktion realisierbar ist.

Wenn Go-Schnittstellen den Typ des Implementierers erfassen könnten, könnte es eine Form von Generika geben, die vollständig mit der aktuellen Go-Syntax kompatibel ist – eine Form von Generika mit einem einzigen Parameter ( Demonstration ).

@dc0d für generische Containertypen Ich glaube, dass diese Funktion eine Typüberprüfung zur Kompilierzeit hinzufügt, ohne dass ein Wrappertyp erforderlich ist: https://gist.github.com/pciet/36a9dcbe99f6fb71f5fc2d3c455971e5

@pciet Du hast recht. Im bereitgestellten Code, Nr. 4, Beispiel heißt es, dass der Typ für Slices und Kanäle (und Arrays) erfasst wird. Aber nicht für Karten, denn es gibt nur einen und nur einen Typparameter: den Implementierer. Und da eine Karte zwei Typparameter benötigt, werden Wrapper-Schnittstellen benötigt.

Übrigens muss ich den Demonstrationszweck dieses Codes als Gedankengang betonen. Ich bin kein Sprachdesigner. Dies ist nur eine hypothetische Denkweise über die Implementierung von Generika in Go:

• Kompatibel mit aktuellen Go
• Einfach (einzelner generischer Typparameter, der sich wie _dieser_ in anderen OO anfühlt und sich auf den aktuellen Implementierer bezieht)

Die Erörterung der Generizität und aller möglichen Anwendungsfälle im Zusammenhang mit dem Wunsch, Auswirkungen zu minimieren und gleichzeitig wichtige Anwendungsfälle und Ausdrucksflexibilität zu maximieren, ist eine sehr komplexe Analyse. Ich bin mir nicht sicher, ob einer von uns in der Lage sein wird, es auf eine kurze Reihe von Prinzipien, auch bekannt als generative Essenz, zu reduzieren. Ich versuche. Wie dem auch sei, hier einige meiner ersten Gedanken aus meiner _flüchtigen_ Durchsicht dieses Threads …

@adg schrieb:

Zu dieser Ausgabe gehört ein allgemeiner Generika-Vorschlag von @ianlancetaylor , der vier spezifische fehlerhafte Vorschläge für generische Programmiermechanismen für Go enthält.

Afaics, der verlinkte Abschnitt, der wie folgt ausgezogen ist, gibt keinen Fall von fehlender Generizität bei aktuellen Schnittstellen an: _„Es gibt keine Möglichkeit, eine Methode zu schreiben, die eine Schnittstelle für den vom Aufrufer bereitgestellten Typ T für jedes T akzeptiert und einen Wert von zurückgibt derselbe Typ T.“_.

Es gibt keine Möglichkeit, eine Schnittstelle mit einer Methode zu schreiben, die ein Argument vom Typ T für ein beliebiges T akzeptiert und einen Wert desselben Typs zurückgibt.

Wie sonst könnte der Code beim Aufruf-Site-Typ überprüfen, ob er einen Typ T als Ergebniswert hat? Beispielsweise kann die besagte Schnittstelle eine Factory-Methode zum Erstellen von Typ T haben. Aus diesem Grund müssen wir Schnittstellen auf Typ T parametrisieren.

Schnittstellen sind nicht einfach Typen; sie sind auch Werte. Es gibt keine Möglichkeit, Schnittstellentypen ohne Schnittstellenwerte zu verwenden, und Schnittstellenwerte sind nicht immer effizient.

Einverstanden, dass der Typ T für den Programmierer nicht zugänglich ist, da Schnittstellen derzeit nicht explizit auf den Typ T parametrisiert werden können, auf dem sie arbeiten.

Das also tun Typklassengrenzen auf der Funktionsdefinitionsseite, die einen Typ T als Eingabe nehmen und eine where - oder requires -Klausel haben, die die Schnittstelle(n) angibt, die für Typ T erforderlich sind. In vielen Fällen Diese Schnittstellenwörterbücher können zur Kompilierzeit automatisch monomorphisiert werden, sodass zur Laufzeit keine Wörterbuchzeiger (für die Schnittstellen) an die Funktion übergeben werden (Monomorphisierung, von der ich annehme, dass der Go-Compiler derzeit auf Schnittstellen anwendet?). Ich nehme an, dass er mit „Werten“ im obigen Zitat den Eingabetyp T meint und nicht das Wörterbuch der Methoden für den vom Typ T implementierten Schnittstellentyp.

Wenn wir dann Typparameter für Datentypen zulassen (z. B. struct ), dann kann der oben genannte Typ T selbst parametrisiert werden, sodass wir wirklich einen Typ T<U> haben. Fabriken für solche Typen, die das Wissen über U behalten müssen, werden höherwertige Typen (HKT) genannt.

Generics erlauben typsichere polymorphe Container.

Vgl. auch das weiter unten diskutierte Problem der _heterogenen_ Container. Mit polymorph meinen wir also die Generizität des Werttyps des Containers (z. B. Elementtyp der Sammlung), aber es stellt sich auch die Frage, ob wir mehr als einen Werttyp gleichzeitig in den Container einfügen können, um sie heterogen zu machen.

@tamird schrieb:

Diese Anforderungen scheinen z. B. ein dem Trait-System von Rust ähnliches System auszuschließen, bei dem generische Typen durch Trait-Grenzen eingeschränkt werden.

Die Eigenschaftsgrenzen von Rust sind im Wesentlichen Typklassengrenzen.

@alex schrieb:

Rusts Eigenschaften. Obwohl ich denke, dass sie im Allgemeinen ein gutes Modell sind, würden sie schlecht zu Go passen, wie es heute existiert.

Warum denkst du, dass sie schlecht passen? Vielleicht denken Sie an die Trait-Objekte, die Runtime-Dispatch verwenden, also weniger leistungsfähig sind als Monomorphismus? Aber diese können getrennt vom Typklassengrenzen-Generitätsprinzip betrachtet werden (vgl. meine Diskussion über heterogene Container/Sammlungen weiter unten). Die Schnittstellen von Afaics, Go sind bereits merkmalsähnliche Grenzen und erreichen das Ziel von Typklassen, die Wörterbücher zu spät an die Datentypen an der Aufrufstelle zu binden, und nicht das Antimuster von OOP, das früh bindet (selbst wenn es noch beim Kompilieren ist). Zeit) Wörterbücher zu Datentypen (bei Instanziierung/Konstruktion). Typklassen können (zumindest eine teilweise Verbesserung der Freiheitsgrade) das Ausdrucksproblem lösen, was OOP nicht kann.

@jimmyfrasche schrieb:

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

Ich stimme dem obigen Link zu, dass Typklassen tatsächlich keine Untertypisierung sind und keine Vererbungsbeziehung ausdrücken. Und stimmen Sie zu, „Generizität“ (als ein allgemeineres Konzept der Wiederverwendung oder Modularität als parametrischer Polymorphismus) nicht unnötigerweise mit Vererbung zu verschmelzen, wie dies bei Unterklassen der Fall ist.

Allerdings möchte ich auch darauf hinweisen, dass Vererbungshierarchien (auch ^Subtyping genannt) bei der Zuweisung an (Funktionseingaben) und von (Funktionsausgaben) unvermeidlich sind, wenn die Sprache Vereinigungen und Schnittmengen unterstützt, weil zum Beispiel ein int ν string kann eine Zuweisung von einem int oder string annehmen, aber keiner kann eine Zuweisung von einem int ν string annehmen. Ohne Vereinigungen sind die einzigen alternativen Möglichkeiten, statisch typisierte heterogene Container/Sammlungen bereitzustellen, Unterklassen oder existenziell begrenzter Polymorphismus (auch bekannt als Trait-Objekte in Rust und existenzielle Quantifizierung in Haskell). Die obigen Links enthalten Diskussionen über die Kompromisse zwischen Existentials und Gewerkschaften. Afaik, die einzige Möglichkeit, heterogene Container/Sammlungen in Go zu erstellen, besteht jetzt darin, alle Typen in ein leeres interface{} zu subsumieren, wodurch die Typisierungsinformationen weggeworfen werden und ich annehme, dass Umwandlungen und Laufzeit-Typprüfung erforderlich sind, welche Art von ² besiegt den Punkt der statischen Typisierung.

Das zu vermeidende „Anti-Muster“ ist die Unterklassenbildung, auch bekannt als virtuelle Vererbung (vgl. auch „EDIT#2“ zu den Problemen mit impliziter Subsumtion und Gleichheit usw.).

¹ _{Unabhängig davon, ob sie strukturell oder nominell übereinstimmen, da die Subtypisierung aufgrund des Liskov-Substitutionsprinzips auf der Grundlage von Vergleichsmengen und der Zuweisungsrichtung mit Funktionseingängen entgegengesetzt zu Rückgabewerten erfolgt, z. B. ein Typparameter von struct oder interface kann nicht sowohl in den Funktionseingaben als auch in den Rückgabewerten vorhanden sein, es sei denn, es ist invariant anstelle von Co- oder Contra-Variante.}

² _{Absolutismus gilt nicht, weil wir das Universum des unbegrenzten Nichtdeterminismus nicht typisieren können. So wie ich es verstehe, geht es in diesem Thread darum, eine optimale ("Sweet Spot") Grenze für die Ebene der Angabe der Typisierung in Bezug auf die Probleme der Generizität zu wählen.}

@andrewcmyers schrieb:

Im Gegensatz zu Java- und C#-Generika basiert der Genus-Generika-Mechanismus nicht auf Subtypisierung.

Es ist die Vererbung und Unterklassenbildung ( nicht die strukturelle Untertypisierung ), die das schlechteste Anti-Muster ist, das Sie nicht von Java, Scala, Ceylon und C++ kopieren möchten (unabhängig von den Problemen mit C++-Vorlagen ).

@thwd schrieb:

Der Exponent des Komplexitätsmaßes parametrisierter Typen ist die Varianz. Die Typen von Go (mit Ausnahme von Schnittstellen) sind unveränderlich, und dies kann und sollte als Regel beibehalten werden.

Die Subtypisierung mit Unveränderlichkeit umgeht die Komplexität der Kovarianz. Unveränderlichkeit verbessert auch einige der Probleme mit Unterklassenbildung (z. B. Rectangle vs. Square ), aber nicht andere (z. B. implizite Subsumtion, Gleichheit usw.).

@bxqgit schrieb:

Einfache Syntax und Typsystem sind die wichtigen Vorteile von Go. Wenn Sie Generika hinzufügen, wird die Sprache zu einem hässlichen Durcheinander wie Scala oder Haskell.

Beachten Sie, dass Scala versucht, OOP, Subsclassing, FP, generische Module, HKT und Typklassen (über implicit ) in einer PL zusammenzuführen. Vielleicht reichen Typklassen allein aus.

Haskell ist nicht unbedingt wegen Typklassen-Generika stumpfsinnig, sondern wahrscheinlicher, weil es überall reine Funktionen erzwingt und die monadische Kategorientheorie verwendet, um kontrollierte imperative Effekte zu modellieren.

Daher denke ich, dass es nicht richtig ist, die Stumpfheit und Komplexität dieser PLs mit Typklassen in beispielsweise Rust in Verbindung zu bringen. Und lassen Sie uns nicht Typklassen für Rusts Lebenszeit+exklusive Mutabilitätsausleihe-Abstraktion verantwortlich machen.

Afaics, im Semantics -Abschnitt von _Type Parameters in Go_, ist das Problem, auf das @ianlancetaylor stößt, ein Konzeptualisierungsproblem, weil er ( Afaics ) anscheinend unwissentlich Typklassen neu erfindet:

Können wir SortableSlice und PSortableSlice zusammenführen, um das Beste aus beiden Welten zu haben? Nicht ganz; Es gibt keine Möglichkeit, eine parametrisierte Funktion zu schreiben, die entweder einen Typ mit einer Less -Methode oder einen eingebauten Typ unterstützt. Das Problem besteht darin, dass SortableSlice.Less für einen Typ ohne eine Less -Methode nicht instanziiert werden kann und dass es keine Möglichkeit gibt, nur für einige Typen eine Methode zu instanziieren, für andere jedoch nicht.

Die requires Less[T] -Klausel für die gebundene Typklasse (auch wenn sie vom Compiler implizit abgeleitet wird) in der Less -Methode für []T ist auf T und nicht []T . Die Implementierung der Typklasse Less[T] (die eine Methode Less enthält) für jede T stellt entweder eine Implementierung im Funktionsrumpf der Methode bereit oder weist < zu U[T] erfordert, wenn die Methoden von Sortable[U] einen Typparameter U $ benötigen, der den implementierenden Typ darstellt, z. B. []T . Afair @keean hat eine andere Möglichkeit , eine Sortierung zu strukturieren, indem eine separate Typklasse für den Werttyp T verwendet wird, für die kein HKT erforderlich ist.

Beachten Sie, dass diese Methoden für []T möglicherweise eine Typklasse Sortable[U] implementieren, wobei U []T ist.

(Abgesehen von der Technik: Es scheint, dass wir SortableSlice und PSortableSlice zusammenführen könnten, indem wir einen Mechanismus hätten, um eine Methode nur für einige Typargumente zu instanziieren, aber nicht für andere. Das Ergebnis wäre jedoch, die Kompilierung zu opfern -time Typsicherheit, da die Verwendung des falschen Typs zu einer Laufzeitpanik führen würde. In Go kann man bereits Schnittstellentypen und -methoden und Typzusicherungen verwenden, um das Verhalten zur Laufzeit auszuwählen. Es muss keine andere Möglichkeit bereitgestellt werden, dies mit Typparametern zu tun .)

Die Auswahl der an der Aufrufstelle gebundenen Typklasse wird zur Kompilierzeit für ein statisch bekanntes T aufgelöst. Wenn ein heterogener dynamischer Versand erforderlich ist, sehen Sie sich die Optionen an, die ich in meinem vorherigen Beitrag erläutert habe.

Ich hoffe, @keean findet Zeit, hierher zu kommen und zu helfen, Typklassen zu erklären, da er Experte ist und mir geholfen hat, diese Konzepte zu lernen. Ich könnte einige Fehler in meiner Erklärung haben.

PS Hinweis für diejenigen, die meinen vorherigen Beitrag bereits gelesen haben, beachten Sie, dass ich ihn etwa 10 Stunden nach dem Posten (nach etwas Schlaf) ausführlich bearbeitet habe, um hoffentlich die Punkte zu heterogenen Containern kohärenter zu machen.

Der Abschnitt " Zyklen " scheint falsch zu sein. Die Laufzeitkonstruktion der S[T]{e} -Instanz eines struct hat nichts mit der Auswahl der Implementierung der aufgerufenen generischen Funktion zu tun. Er denkt vermutlich, dass der Compiler nicht weiß, ob er die Implementierung der generischen Funktion für den Typ der Argumente spezialisiert, aber alle diese Typen sind zur Kompilierzeit bekannt.

Vielleicht könnte die Spezifikation des Typüberprüfungsabschnitts vereinfacht werden, indem das @ keean -Konzept eines verbundenen Graphen verschiedener Typen als Knoten für einen Vereinigungsalgorithmus untersucht wird. Alle unterschiedlichen Typen, die durch eine Kante verbunden sind, müssen kongruente Typen haben, wobei Kanten für alle Typen erstellt werden, die über eine Zuweisung oder anderweitig im Quellcode verbunden sind. Wenn es Union und Schnittpunkt gibt (aus meinem vorherigen Post), dann muss die Richtung der Zuordnung berücksichtigt werden ( irgendwie? ). Jeder unterschiedliche unbekannte Typ beginnt mit einer kleinsten Obergrenze (LUB) von Top und einer größten Untergrenze (GLB) von Bottom , und dann können Einschränkungen diese Grenzen ändern. Verbundene Typen müssen kompatible Grenzen haben. Einschränkungen sollten alle Typklassengrenzen sein.

In Umsetzung :

Beispielsweise ist es immer möglich, parametrisierte Funktionen zu implementieren, indem für jede Instanziierung eine neue Kopie der Funktion generiert wird, wobei die neue Funktion erstellt wird, indem die Typparameter durch die Typargumente ersetzt werden.

Ich glaube, der richtige Fachbegriff ist Monomorphisierung .

Dieser Ansatz würde die effizienteste Ausführungszeit auf Kosten einer beträchtlichen zusätzlichen Kompilierzeit und einer erhöhten Codegröße ergeben. Es ist wahrscheinlich eine gute Wahl für parametrisierte Funktionen, die klein genug für Inline sind, aber in den meisten anderen Fällen wäre es ein schlechter Kompromiss.

Die Profilerstellung würde dem Programmierer mitteilen, welche Funktionen am meisten von der Monomorphisierung profitieren können. Vielleicht führt der Java-Hotspot-Optimierer zur Laufzeit eine Monomorphisierungsoptimierung durch?

@egonelbre schrieb:

Es gibt eine Zusammenfassung der Go Generics-Diskussionen , die versucht, einen Überblick über Diskussionen von verschiedenen Orten zu geben.

Der Übersichtsabschnitt scheint zu implizieren, dass Javas universelle Verwendung von Boxing-Referenzen für Instanzen in einem Container die einzige Designachse ist, die der Monomorphisierung von Templates in C++ diametral entgegengesetzt ist. Aber Typklassengrenzen (die auch mit C++-Vorlagen implementiert werden können, aber immer monomorphisiert sind) werden auf Funktionen angewendet, nicht auf Parameter vom Containertyp. Daher fehlt in der Übersicht afaics die Designachse für Typklassen, in der wir wählen können, ob wir jede Typklassen-begrenzte Funktion monomorphisieren möchten. Mit Typklassen machen wir Programmierer immer schneller (weniger Boilerplate) und können ein verfeinertes Gleichgewicht zwischen schnelleren/langsameren Compilern/Ausführung und größerem/geringerem Aufblähen des Codes erreichen. Laut meinem vorherigen Beitrag wäre es vielleicht das Optimum, wenn die Auswahl der zu monomorphisierenden Funktionen vom Profiler gesteuert würde (automatisch oder wahrscheinlicher durch Anmerkung).

Im Abschnitt Probleme: Generische Datenstrukturen :

Nachteile

• Generische Strukturen neigen dazu, Features aus allen Verwendungen zu akkumulieren, was zu längeren Kompilierungszeiten oder Code-Aufblähung führt oder einen intelligenteren Linker benötigt.

Für Typklassen gilt dies entweder nicht oder ist weniger problematisch, da Schnittstellen nur für Datentypen implementiert werden müssen, die an Funktionen geliefert werden, die diese Schnittstellen verwenden. Bei Typklassen geht es um die späte Bindung der Implementierung an die Schnittstelle, im Gegensatz zu OOP, das jeden Datentyp an seine Methoden für die class -Implementierung bindet.

Außerdem müssen nicht alle Methoden in einer einzigen Schnittstelle untergebracht werden. Die requires -Klausel (auch wenn sie implizit vom Compiler abgeleitet wird) in einer Typklasse, die für eine Funktionsdeklaration gebunden ist, kann die erforderlichen Schnittstellen mischen und abgleichen.

• Generische Strukturen und die APIs, die auf ihnen arbeiten, sind in der Regel abstrakter als speziell entwickelte APIs, was den Aufrufern eine kognitive Belastung auferlegen kann

Ein Gegenargument, das meiner Meinung nach diese Bedenken erheblich mildert, ist, dass die kognitive Belastung durch das Erlernen einer unbegrenzten Anzahl von Sonderfall-Neuimplementierungen der im Wesentlichen gleichen generischen Algorithmen unbegrenzt ist. Wohingegen das Lernen der abstrakten generischen APIs begrenzt ist.

• Tiefenoptimierungen sind sehr nicht generisch und kontextspezifisch, daher ist es schwieriger, sie in einem generischen Algorithmus zu optimieren.

Dies ist kein gültiger Betrug. Die 80/20-Regel sagt, fügen Sie keine unbegrenzte Komplexität (z. B. vorzeitige Optimierung) für Code hinzu, der, wenn er profiliert wird, dies nicht erfordert. Der Programmierer kann in 20 % der Fälle optimieren, während die restlichen 80 % von der begrenzten Komplexität und kognitiven Belastung der generischen APIs bewältigt werden.

Worauf wir hier wirklich hinaus wollen, ist die Regelmäßigkeit einer Sprache und generischer APIs helfen, nicht schaden. Diese Nachteile sind wirklich nicht richtig begriffen.

Alternativlösungen:

• Verwenden Sie einfachere Strukturen anstelle komplizierter Strukturen
  
  
  
  • Verwenden Sie zB map[int]struct{} anstelle von Set
  
  

Rob Pike (und ich habe auch gesehen, wie er diesen Punkt im Video betont hat) scheint den Punkt zu übersehen, dass generische Container nicht ausreichen, um generische Funktionen zu erstellen. Wir brauchen dieses T in map[T] , damit wir den generischen Datentyp in Funktionen für Eingaben, Ausgaben und für unsere eigenen struct weitergeben können. Generika nur für Containertypparameter sind völlig unzureichend, um generische APIs auszudrücken, und generische APIs sind erforderlich, um die Komplexität und kognitive Belastung zu begrenzen und Regelmäßigkeit in einem Sprachökosystem zu erhalten. Außerdem habe ich nicht das erhöhte Maß an Refactoring gesehen (daher die reduzierte Zusammensetzbarkeit von Modulen, die nicht einfach umgestaltet werden können), die nicht-generischer Code erfordert, und darum geht es beim Ausdrucksproblem, das ich in meinem ersten Beitrag erwähnt habe.

Im Abschnitt Generische Ansätze :

Paketvorlagen
Dies ist ein Ansatz, der von Modula-3, OCaml, SML (sogenannte „Funktoren“) und Ada verwendet wird. Anstatt einen individuellen Typ für die Spezialisierung anzugeben, ist das gesamte Paket generisch. Sie spezialisieren das Paket, indem Sie beim Importieren die Typparameter festlegen.

Ich kann mich irren, aber das scheint nicht ganz richtig zu sein. ML-Funktoren (nicht zu verwechseln mit FP-Funktoren) können auch eine Ausgabe zurückgeben, die typparametriert bleibt. Es gäbe sonst keine Möglichkeit, die Algorithmen in anderen generischen Funktionen zu verwenden, sodass generische Module nicht in der Lage wären, andere generische Module wiederzuverwenden (durch Importieren mit konkreten Typen in). Dies scheint ein Versuch zu sein, den Punkt der Generika, der Wiederverwendung von Modulen usw. zu stark zu vereinfachen und dann völlig zu verfehlen.

Mein Verständnis ist eher, dass diese Parametrisierung des Pakettyps (auch bekannt als Modul) die Möglichkeit ermöglicht, Typparameter auf eine Gruppierung von struct , interface und func anzuwenden.

Komplizierteres Typensystem
Dies ist der Ansatz, den Haskell und Rust verfolgen.
[…]
Nachteile:

• schwer in eine einfachere Sprache zu passen (https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwGlB-n40kJ)

Zitieren von @ianlancetaylor im verlinkten Dokument:

Wenn Sie das glauben, dann lohnt es sich darauf hinzuweisen, dass der Kern der
Map- und Slice-Code in der Go-Laufzeit ist nicht generisch im Sinne von
Typpolymorphismus verwenden. Es ist generisch in dem Sinne, dass es betrachtet
Geben Sie Reflexionsinformationen ein, um zu sehen, wie Sie Schrift verschieben und vergleichen können
Werte. Wir haben also den Existenzbeweis, dass es akzeptabel ist, zu schreiben
"generischer" Code in Go, indem nicht-polymorpher Code geschrieben wird, der Typ verwendet
Reflektionsinformationen effizient zu reflektieren und diesen Code dann einzuschließen
typsichere Boilerplate zur Kompilierzeit (im Fall von Maps und Slices
diese Textbausteine ​​werden natürlich vom Compiler bereitgestellt).

Und genau das würde ein Compiler, der aus einer Obermenge von Go mit hinzugefügten Generika transpiliert, als Go-Code ausgeben. Aber die Verpackung würde nicht auf einer Abgrenzung wie einer Verpackung basieren, da dies die bereits erwähnte Zusammensetzbarkeit verfehlen würde. Der Punkt ist, dass es keine Abkürzung zu einem guten zusammensetzbaren generischen Typsystem gibt. Entweder wir machen es richtig oder wir machen nichts, denn das Hinzufügen eines nicht komponierbaren Hacks, der nicht wirklich generisch ist, wird schließlich eine Clusterfuck-Trägheit von Patchwork, halbherziger Generizität und Unregelmäßigkeit von Eckfällen und Problemumgehungen erzeugen, die Go-Ökosystem-Code machen unverständlich.

Es stimmt auch, dass die meisten Leute große, komplexe Go-Programme schreiben
kein nennenswerter Bedarf an Generika festgestellt. Bisher war es eher so
eine irritierende Warze - die Notwendigkeit, drei Zeilen Textbausteine ​​dafür zu schreiben
jeder Typ muss sortiert werden - eher als ein großes Hindernis, um nützlich zu schreiben
Code.

Ja, das war einer der Gedanken in meinem Kopf, ob es gerechtfertigt ist, zu einem ausgewachsenen Typklassensystem zu gehen. Wenn alle Ihre Bibliotheken darauf basieren, könnte es anscheinend eine schöne Harmonie sein, aber wenn wir über die Trägheit bestehender Go-Hacks für Generizität nachdenken, dann wird die zusätzliche Synergie vielleicht für viele Projekte gering sein ?

Aber wenn ein Transpiler aus einer Typklassensyntax die vorhandene manuelle Art und Weise emuliert, wie Go Generika modellieren kann (Bearbeiten: was ich gerade gelesen habe, dass @andrewcmyers angibt, ist plausibel ), könnte dies weniger belastend sein und nützliche Synergien finden. Zum Beispiel habe ich festgestellt, dass zwei Parametertypklassen mit interface emuliert werden können, das auf einem struct $ implementiert ist, das ein Tupel emuliert, oder @jba hat eine Idee erwähnt , um interface inline im Kontext zu verwenden . Anscheinend sind struct strukturell statt nominell typisiert, es sei denn, man erhält einen Namen mit type ? Außerdem habe ich bestätigt, dass eine Methode von interface weitere interface eingeben kann, so dass es möglich sein kann, von HKT in Ihrem Sortierbeispiel, über das ich in meinem vorherigen Beitrag hier geschrieben habe, zu transpilieren. Aber ich muss darüber nachdenken, wenn ich nicht so müde bin.

Ich denke, es ist fair zu sagen, dass die meisten im Go-Team C++ nicht mögen
Templates, in denen eine vollständige Turing-Sprache überlagert wurde
eine andere Turing-Sprache vollständig, so dass die beiden Sprachen haben
völlig unterschiedliche Syntaxen und Programme in beiden Sprachen sind
ganz unterschiedlich geschrieben. C++-Vorlagen dienen als Warnung
Geschichte, weil die komplexe Implementierung das Ganze durchdrungen hat
Standardbibliothek, wodurch C++-Fehlermeldungen zu einer Quelle von werden
Staunen und Staunen. Dies ist kein Weg, dem Go jemals folgen wird.

Ich bezweifle, dass irgendjemand anderer Meinung sein wird! Der Vorteil der Monomorphisierung ist orthogonal zu den Nachteilen einer vollständigen generischen Metaprogrammierungs-Engine von Turing.

Übrigens scheint mir der Designfehler von C++-Vorlagen die gleiche generative Essenz des Fehlers von generativen (im Gegensatz zu applikativen) ML-Funktoren zu sein. Es gilt das Prinzip der geringsten Leistung.

@ianlancetaylor schrieb:

Es ist enttäuschend zu sehen, dass Go immer komplexer wird, indem eingebaute parametrisierte Typen hinzugefügt werden.

Trotz der Spekulationen in dieser Ausgabe halte ich dies für äußerst unwahrscheinlich.

Hoffentlich. Ich bin der festen Überzeugung, dass Go entweder ein kohärentes Generika-System hinzufügen oder einfach akzeptieren sollte, dass es niemals Generika geben wird.

Ich denke, dass ein Fork zu einem Transpiler eher passieren wird, zum Teil, weil ich die Finanzierung habe, um ihn zu implementieren, und daran interessiert bin. Trotzdem analysiere ich die Situation.

Das würde zwar das Ökosystem zerbrechen, aber zumindest kann Go dann seinen minimalistischen Prinzipien treu bleiben. Um das Ökosystem nicht zu zerbrechen und einige andere Innovationen zuzulassen, die ich gerne hätte, würde ich es wahrscheinlich nicht zu einer Obermenge machen und es stattdessen Zero nennen .

@pciet schrieb:

Meine Stimme ist Nein zu generalisierten Anwendungsgenerika, Ja zu mehr integrierten generischen Funktionen wie append und copy , die auf mehreren Basistypen funktionieren. Vielleicht könnten sort und search für die Sammlungstypen hinzugefügt werden?

Die Ausweitung dieser Trägheit wird vielleicht verhindern, dass ein umfassendes Generika-Feature jemals in Go aufgenommen wird. Diejenigen, die Generika wollten, werden wahrscheinlich auf grünere Weiden aufbrechen. @andrewcmyers wiederholte dies:

Es wäre enttäuschend zu sehen, wie Go immer komplexer wird, indem eingebaute parametrisierte Typen hinzugefügt werden. Es wäre besser, nur die Sprachunterstützung hinzuzufügen, damit Programmierer ihre eigenen parametrisierten Typen schreiben können.

@ shelby3

Afaik, die einzige Möglichkeit, heterogene Container/Sammlungen in Go zu erstellen, besteht jetzt darin, alle Typen in einer leeren Schnittstelle zusammenzufassen{}, die die Typisierungsinformationen wegwirft, und würde, wie ich annehme, Umwandlungen und eine Typprüfung zur Laufzeit erfordern, was irgendwie2 den Sinn verfehlt statische Typisierung.

Sehen Sie sich das Wrapper-Muster in den obigen Kommentaren für die statische Typprüfung von Interface{}-Sammlungen in Go an.

Der Punkt ist, dass es keine Abkürzung zu einem guten zusammensetzbaren generischen Typsystem gibt. Entweder wir machen es richtig oder gar nichts, denn das Hinzufügen eines nicht komponierbaren Hacks, der nicht wirklich generisch ist …

Können Sie das näher erläutern? Für den Fall der Sammlungstypen scheint es vernünftig zu sein, eine Schnittstelle zu haben, die das notwendige generische Verhalten enthaltener Elemente definiert, um Funktionen zu schreiben.

@pciet Dieser Code macht buchstäblich genau das, was @shelby3 beschrieben hat, und erwägt ein Antimuster. Ich zitiere dich von vorhin:

Dies enthält Dokumentations- und Testbeispiele, die das Typ-Wrapper-Muster (danke @pierrre) für Typsicherheit zur Kompilierungszeit und auch die Reflexionsprüfung für Typsicherheit zur Laufzeit enthalten.

Sie nehmen Code, dem Typinformationen fehlen, und fügen Typ-für-Typ-Umwandlungen und Laufzeit-Typprüfungen mithilfe von Reflect hinzu. Genau darüber hat sich @shelby3 beschwert. Ich neige dazu, diesen Ansatz "Monomorphisierung von Hand" zu nennen, und es ist genau die Art von mühsamer Arbeit, die meiner Meinung nach am besten einem Compiler überlassen wird.

Dieser Ansatz hat eine Reihe von Nachteilen:

• Erfordert Typ-für-Typ-Wrapper, die entweder von Hand oder mit einem go generate -ähnlichen Werkzeug verwaltet werden
• (Wenn es von Hand statt mit einem Tool gemacht wird) Gelegenheit, Fehler in der Boilerplate zu machen, die erst zur Laufzeit abgefangen werden
• Erfordert dynamisches Dispatch anstelle von statischem Dispatch, das sowohl langsamer ist als auch mehr Arbeitsspeicher benötigt
• Verwendet Runtime Reflection anstelle von Assertionen zur Kompilierzeit, was ebenfalls langsam ist
• Nicht zusammensetzbar: wirkt vollständig auf konkrete Typen ohne Möglichkeiten, typklassenähnliche (oder sogar schnittstellenähnliche) Grenzen für Typen zu verwenden, es sei denn, Sie handrollen eine weitere Indirektionsebene für jede nicht leere Schnittstelle, über die Sie auch abstrahieren möchten

Können Sie das näher erläutern? Für den Fall der Sammlungstypen scheint es vernünftig zu sein, eine Schnittstelle zu haben, die das notwendige generische Verhalten enthaltener Elemente definiert, um Funktionen zu schreiben.

Überall dort, wo Sie anstelle oder zusätzlich zu einem konkreten Typ eine Bindung verwenden möchten, müssen Sie auch für jeden Schnittstellentyp die gleiche Typprüfungs-Boilerplate schreiben. Es verschlimmert nur die (vielleicht kombinatorische) Explosion von Wrappern statischen Typs, die Sie schreiben müssen.

Es gibt auch Ideen, die, soweit ich weiß, heute in Gos Typensystem überhaupt nicht mehr ausgedrückt werden können, wie zum Beispiel eine Bindung an eine Kombination von Schnittstellen. Stellen Sie sich vor, wir haben:

type Foo interface {
    ...
}

type Bar interface {
    ...
}

Wie drücken wir mit einer rein statischen Typprüfung aus, dass wir einen Typ wollen, der sowohl Foo als auch Bar implementiert? Soweit ich weiß, ist dies in Go nicht möglich (ohne auf Laufzeitprüfungen zurückzugreifen, die möglicherweise fehlschlagen, und auf statische Typsicherheit zu verzichten).

Mit einem Typklassen-basierten Generika-System könnten wir dies wie folgt ausdrücken:

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

@tarcieri

Wie drücken wir mit einer rein statischen Typprüfung aus, dass wir einen Typ wollen, der sowohl Foo als auch Bar implementiert?

einfach so:

type T interface {
    Foo
    Bar
}

func baz(t T) { ... }

@sbinet ordentlich, BIS

Persönlich halte ich die Laufzeitreflexion für eine Fehlfunktion, aber das bin nur ich ... Ich kann erklären, warum, wenn es jemanden interessiert.

Ich denke, jeder, der Generika jeglicher Art implementiert, sollte Stepanovs "Elements of Programming" zuerst mehrmals lesen. Es würde viele Not Invented Here-Probleme vermeiden und das Rad neu erfinden. Nachdem Sie das gelesen haben, sollte klar sein, warum „C++-Konzepte“ und „Haskell-Typklassen“ der richtige Weg sind, Generika zu erstellen.

Wie ich sehe, scheint dieses Problem wieder aktiv zu sein
Hier ist ein Spielplatz für Strohmänner
https://go-li.github.io/test.html
Fügen Sie einfach Demoprogramme von hier ein
https://github.com/go-li/demo

Vielen Dank für Ihre Bewertung dieses einzelnen Parameters
Funktionen Generika.

Wir pflegen das gehackte gccgo und
Dieses Projekt wäre ohne Sie nicht möglich, also wir
wollte etwas zurückgeben.

Wir freuen uns auch auf die Generika, die Sie verwenden, machen Sie weiter mit der großartigen Arbeit!

@anlhord wo sind die Implementierungsdetails dazu? Wo kann man die Syntax nachlesen? Was wird umgesetzt? Was ist nicht implementiert? Was sind die Spezifikationen für diese Implementierungen? Was sind die Vor- und Nachteile dafür?

Der Spielplatz-Link enthält das denkbar schlechteste Beispiel dafür:

package main

import "fmt"

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

Dieser Code sagt mir nichts darüber, wie man ihn benutzt und was ich testen kann.

Wenn Sie diese Dinge verbessern könnten, würde dies helfen, besser zu verstehen, was Ihr Vorschlag ist und wie er im Vergleich zu den vorherigen Vorschlägen abschneidet / zu sehen, wie die anderen hier angesprochenen Punkte darauf zutreffen oder nicht.

Ich hoffe, dies hilft Ihnen, die Probleme mit Ihrem Kommentar zu verstehen.

@joho schrieb:

Wäre die wissenschaftliche Literatur für Hinweise zur Bewertung von Ansätzen wertvoll?

Das einzige Papier, das ich zu diesem Thema gelesen habe, ist Profitieren Entwickler von generischen Typen ? (Entschuldigung, Paywall, Sie könnten sich zu einem PDF-Download googlen), der Folgendes zu sagen hatte

Folglich eine konservative Interpretation des Experiments
ist, dass generische Typen als Kompromiss betrachtet werden können
zwischen den positiven Dokumentationsmerkmalen und der
negative Dehnbarkeitseigenschaften.

Ich nehme an, OOP und Unterklassen (z. B. Klassen in Java und C++) werden beide nicht ernsthaft in Betracht gezogen, da Go bereits eine Typklasse wie interface hat (ohne den expliziten generischen Typparameter T ), Java schon zitiert, was nicht kopiert werden sollte, und weil viele argumentiert haben, dass sie ein Anti-Muster sind. Upthread Ich habe einige dieser Argumente verlinkt. Wir könnten diese Analyse vertiefen, wenn es jemanden interessiert.

Neuere Forschungen wie das oben erwähnte Genus-System habe ich noch nicht studiert. Ich bin misstrauisch gegenüber „Küchenspülen“-Systemen, die versuchen, so viele Paradigmen zu mischen (z. B. Unterklassenbildung, Mehrfachvererbung, OOP, Trait-Linearisierung, implicit , Typklassen, abstrakte Typen usw.), aufgrund der Beschwerden über Scala in der Praxis so viele Eckfälle zu haben, obwohl sich das vielleicht mit Scala 3 (auch bekannt als Dotty und der DOT-Kalkül) verbessert. Ich bin neugierig, ob ihre Vergleichstabelle mit der experimentellen Scala 3 oder der aktuellen Version von Scala verglichen wird?

Also afaics, was bleibt, sind ML-Funktoren und Haskell-Typklassen im Sinne von bewährten Generizitätssystemen, die die Erweiterbarkeit und Flexibilität im Vergleich zu OOP+Unterklassifizierung erheblich verbessern.

Ich habe einige der privaten Diskussionen aufgeschrieben, die @keean und ich über ML-Funktormodule im Vergleich zu Typklassen geführt haben. Die Highlights scheinen zu sein:

• Typklassen _modellieren eine Algebra_ (aber ohne überprüfte Axiome ) und implementieren jeden Datentyp für jede Schnittstelle nur auf eine Weise. Dadurch wird eine implizite Auswahl der Implementierungen durch den Compiler ohne Annotation an der Aufrufstelle ermöglicht.

• Applikative Funktoren haben referenzielle Transparenz, während generative Funktoren bei jeder Instanziierung eine neue Instanz erstellen, was bedeutet, dass sie nicht invariant in der Initialisierungsreihenfolge sind.

• ML-Funktoren sind leistungsfähiger/flexibler als Typklassen, aber dies geht auf Kosten von mehr Anmerkungen und potenziell mehr Eckfallinteraktionen. Und laut @keean benötigen sie abhängige Typen (für zugeordnete Typen ), was ein komplexeres Typsystem ist. @keean hält Stepanovs _Ausdruck der Generizität als Algebra_ plus Typklassen für ausreichend leistungsfähig und flexibel, so dass dies der ideale Punkt für hochmoderne, gut bewährte (in Haskell und jetzt in Rust) Generizität zu sein scheint. Die Axiome werden jedoch nicht durch Typklassen erzwungen .

• Ich habe vorgeschlagen, Vereinigungen für heterogene Container mit Typklassen hinzuzufügen, die sich entlang einer anderen Achse des Ausdrucksproblems erstrecken sollen, obwohl dies Unveränderlichkeit oder Kopieren erfordert (nur für die Fälle, in denen die heterogene Erweiterbarkeit verwendet wird), von denen bekannt ist, dass sie ein O (log n) haben.

@larst schrieb:

Es könnte interessant sein, einen oder mehrere experimentelle Transpiler zu haben - einen Go-Generika-Quellcode für Go 1.xy-Quellcode-Compiler.

_{PS: Ich bezweifle, dass Go ein so ausgefeiltes Typisierungssystem übernehmen wird, aber ich erwäge einen Transpiler für die bestehende Go-Syntax, wie ich in meinem vorherigen Beitrag erwähnt habe (siehe die Bearbeitung unten). Und ich möchte ein robustes generisches System zusammen mit diesen sehr wünschenswerten Go-Funktionen. Typeclass-Generika auf Go scheinen das zu sein, was ich will.}

@bcmills schrieb über seinen Vorschlag zu Kompilierzeitfunktionen für Generizität:

Ich habe gehört, dass das gleiche Argument verwendet wurde, um für den Export interface -Typen statt konkreter Typen in Go-APIs einzutreten, und es stellt sich heraus, dass das Gegenteil häufiger vorkommt: vorzeitige Abstraktion überfordert die Typen und behindert die Erweiterung von APIs. (Für ein solches Beispiel siehe #19584.) Wenn Sie sich auf diese Argumentationslinie verlassen wollen, müssen Sie meiner Meinung nach einige konkrete Beispiele liefern.

Es ist sicherlich richtig, dass Typsystem-Abstraktionen zwangsläufig einige Freiheitsgrade aufgeben, und manchmal sind wir mit „unsicher“ (dh unter Verletzung der statisch geprüften Abstraktion) aus diesen Beschränkungen ausgebrochen, aber das muss gegen die Vorteile von abgewogen werden modulare Entkopplung mit prägnant annotierten Invarianten.

Beim Entwerfen eines Systems für Generizität möchten wir wahrscheinlich die Regelmäßigkeit und Vorhersagbarkeit des Ökosystems als eines der Hauptziele erhöhen, insbesondere wenn die Kernphilosophie von Go berücksichtigt wird (z. B. dass durchschnittliche Programmierer Priorität haben).

Es gilt das Prinzip der geringsten Leistung. Die Stärke/Flexibilität der Invarianten, die in Kompilierzeitfunktionen für Generizität „versteckt“ sind, muss gegen ihre Fähigkeit abgewogen werden, beispielsweise die Lesbarkeit des Quellcodes im Ökosystem zu beeinträchtigen (wobei die modulare Entkopplung äußerst wichtig ist, da der Leser dies nicht tut müssen aufgrund impliziter transitiver Abhängigkeiten keine potenziell unbegrenzte Menge an Code lesen, um ein bestimmtes Modul/Paket zu verstehen!). Bei der impliziten Auflösung von Typklassen-Implementierungsinstanzen tritt dieses Problem auf, wenn ihre Algebra nicht eingehalten wird .

Sicher, aber das gilt bereits für viele implizite Einschränkungen in Go, unabhängig von generischen Programmiermechanismen.

Beispielsweise kann eine Funktion einen Parameter vom Typ Schnittstelle erhalten und ihre Methoden zunächst sequentiell aufrufen. Wenn sich diese Funktion später ändert, um diese Methoden gleichzeitig aufzurufen (durch das Spawnen zusätzlicher Goroutinen), wird die Einschränkung "muss für die gleichzeitige Verwendung sicher sein" nicht im Typsystem widergespiegelt.

Aber afaik Go hat nicht versucht, eine Abstraktion zu entwerfen, um diese Effekte zu modularisieren. Rust hat eine solche Abstraktion (was ich übrigens für übertrieben pita/tsuris/limitierend für einige/die meisten Anwendungsfälle halte und ich plädiere für eine einfachere Singlethread-Modellabstraktion, aber leider unterstützt Go nicht die Beschränkung aller erzeugten Goroutinen auf denselben Thread ) . Und Haskell erfordert eine monadische Kontrolle über Effekte , da reine Funktionen für referenzielle Transparenz erzwungen werden.

@alerca schrieb:

Ich denke, der größte Nachteil von abgeleiteten Einschränkungen ist, dass sie es einfach machen, einen Typ so zu verwenden, dass eine Einschränkung eingeführt wird, ohne sie vollständig zu verstehen. Im besten Fall bedeutet dies nur, dass Ihre Benutzer auf unerwartete Kompilierzeitfehler stoßen können, aber im schlimmsten Fall bedeutet dies, dass Sie das Paket für Verbraucher beschädigen können, indem Sie versehentlich eine neue Einschränkung einführen. Explizit spezifizierte Constraints würden dies vermeiden.

Einverstanden. Code in anderen Modulen heimlich brechen zu können, weil die Invarianten der Typen nicht explizit annotiert sind, ist ungeheuer heimtückisch.

@andrewcmyers schrieb:

Um es klar zu sagen, ich halte die Generierung von Code im Makrostil, ob mit gen, cpp, gofmt -r oder anderen Makro-/Vorlagenwerkzeugen, nicht für eine gute Lösung des Generika-Problems, selbst wenn sie standardisiert ist. Es hat die gleichen Probleme wie C++-Templates: aufgeblähter Code, fehlende modulare Typprüfung und Schwierigkeiten beim Debuggen. Es wird schlimmer, wenn Sie beginnen, wie es natürlich ist, generischen Code in Bezug auf anderen generischen Code zu erstellen. Meiner Meinung nach sind die Vorteile begrenzt: Es würde das Leben für die Autoren des Go-Compilers relativ einfach machen und es produziert effizienten Code – es sei denn, es gibt einen Befehls-Cache-Druck, eine häufige Situation in moderner Software!

@keean scheint dir zuzustimmen .

@shelby3 Danke für die Kommentare. Kannst du das nächste mal die Kommentare/Änderungen direkt im Dokument selbst vornehmen. Es ist einfacher zu verfolgen, wo Dinge repariert werden müssen, und einfacher sicherzustellen, dass alle Noten eine angemessene Antwort erhalten.

Der Abschnitt Übersicht scheint zu implizieren, dass Javas universelle Verwendung von Boxing-Referenzen für Instanzen ...

Kommentar hinzugefügt, um klarzustellen, dass es sich nicht um eine umfassende Liste handelt. Es ist hauptsächlich da, damit die Leute den Kern der verschiedenen Kompromisse verstehen. Die vollständige Liste der verschiedenen Ansätze finden Sie weiter unten.

Generische Strukturen neigen dazu, Features aus allen Verwendungen zu akkumulieren, was zu längeren Kompilierungszeiten oder Code-Aufblähung führt oder einen intelligenteren Linker benötigt.
Für Typklassen gilt dies entweder nicht oder ist weniger problematisch, da Schnittstellen nur für Datentypen implementiert werden müssen, die an Funktionen geliefert werden, die diese Schnittstellen verwenden. Bei Typklassen geht es um die späte Bindung der Implementierung an die Schnittstelle, im Gegensatz zu OOP, das jeden Datentyp an seine Methoden für die Klassenimplementierung bindet.

Bei dieser Aussage geht es darum, was langfristig mit generischen Datenstrukturen passiert. Mit anderen Worten, eine generische Datenstruktur endet oft damit, alle verschiedenen Verwendungen zu sammeln – anstatt mehrere kleinere Implementierungen für verschiedene Zwecke zu haben. Schauen Sie sich nur als Beispiel https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html an.

Es ist wichtig zu beachten, dass nur das „mechanische Design“ und „so viel Flexibilität“ nicht ausreichen, um eine gute „Generika-Lösung“ zu erstellen. Es braucht auch gute Anweisungen, wie Dinge verwendet werden sollten und was zu vermeiden ist, und überlegen Sie, wie die Leute es letztendlich verwenden.

Generische Strukturen und die darauf operierenden APIs sind tendenziell abstrakter als speziell entwickelte APIs ...

Ein Gegenargument, das meiner Meinung nach diese Bedenken erheblich mildert, ist, dass die kognitive Belastung des Erlernens einer unbegrenzten Anzahl von Sonderfall-Neuimplementierungen der im Wesentlichen gleichen generischen Algorithmen unbegrenzt ist ...

Hinweis zur kognitiven Belastung vieler ähnlicher APIs hinzugefügt.

Die Neuimplementierungen in Sonderfällen sind in der Praxis nicht unbegrenzt. Sie sehen nur eine feste Anzahl von Spezialisierungen.

Dies ist kein gültiger Betrug.

Sie mögen mit einigen Punkten nicht einverstanden sein, ich bin mit einigen bis zu einem gewissen Grad nicht einverstanden, aber ich verstehe ihren Standpunkt und versuche, die Probleme zu verstehen, mit denen die Menschen täglich konfrontiert sind. Ziel des Dokuments sei es, unterschiedliche Meinungen zu sammeln, nicht zu beurteilen, „wie nervig etwas für jemanden ist“.

Das Dokument bezieht jedoch Stellung zu "Problemen, die auf Probleme der realen Welt zurückzuführen sind", da abstrakte und erleichterte Probleme in Foren dazu neigen, in bedeutungsloses Geschwätz zu verfallen, ohne dass Verständnis aufgebaut wird.

Worauf wir hier wirklich hinaus wollen, ist die Regelmäßigkeit einer Sprache und generischer APIs helfen, nicht schaden.

Sicher, in der Praxis benötigen Sie diese Art der Optimierung möglicherweise nur für weniger als 1 % der Fälle.

Alternativlösungen:

Alternative Lösungen sind nicht als Ersatz für Generika gedacht. Sondern eher eine Liste möglicher Lösungen für verschiedene Arten von Problemen.

Paketvorlagen

Ich kann mich irren, aber das scheint nicht ganz richtig zu sein. ML-Funktoren (nicht zu verwechseln mit FP-Funktoren) können auch eine Ausgabe zurückgeben, die typparametriert bleibt.

Können Sie es klarer formulieren und gegebenenfalls in zwei verschiedene Ansätze aufteilen?

@egonelbre danke auch für die Antwort, damit ich weiß, zu welchen Punkten ich meine Gedanken weiter präzisieren muss.

Kannst du das nächste mal die Kommentare/Änderungen direkt im Dokument selbst vornehmen.

Entschuldigung, ich wünschte, ich könnte dem nachkommen, aber ich habe noch nie die Diskussionsfunktionen von Google Doc verwendet, habe keine Zeit, es zu lernen, und ich bevorzuge es auch, meine Diskussionen auf Github für zukünftige Referenzen verlinken zu können.

Schauen Sie sich nur als Beispiel https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html an.

Das Design der Bibliothek der Scala-Sammlungen wurde von vielen Personen kritisiert, darunter auch von einem ihrer ehemaligen Schlüsselteammitglieder . Ein an LtU geposteter Kommentar ist repräsentativ. Beachten Sie, dass ich Folgendes zu einem meiner früheren Beiträge in diesem Thread hinzugefügt habe, um dies zu beheben:

Ich bin misstrauisch gegenüber „Küchenspülen“-Systemen, die versuchen, so viele Paradigmen zu mischen (z. B. Unterklassenbildung, Mehrfachvererbung, OOP, Trait-Linearisierung, implicit , Typklassen, abstrakte Typen usw.), aufgrund der Beschwerden über Scala in der Praxis so viele Eckfälle zu haben, obwohl sich das vielleicht mit Scala 3 (auch bekannt als Dotty und der DOT-Kalkül) verbessert.

Ich glaube nicht, dass die Sammlungsbibliothek von Scala repräsentativ für Bibliotheken wäre, die für eine PL mit nur Typklassen für Polymorphismus erstellt wurden. Afair verwenden die Scala-Sammlungen das Anti-Vererbungsmuster , das die komplexen Hierarchien verursachte, kombiniert mit implicit -Helfern wie CanBuildFrom , die das Komplexitätsbudget sprengten. Und ich denke, wenn @keeans Argument eingehalten wird, dass Stepanovs _Elements of Programming_ eine Algebra ist, könnte eine elegante Sammlungsbibliothek erstellt werden. Es war die erste Alternative, die ich zu einer auf Funktoren (FP) basierenden Sammlungsbibliothek gesehen hatte (dh Haskell nicht kopierte ), die ebenfalls auf Mathematik basierte. Ich möchte dies in der Praxis sehen, was einer der Gründe ist, warum ich mit ihm am Design eines neuen PL zusammenarbeite/diskutiere. Und von diesem Moment an plane ich, diese Sprache zunächst nach Go transpilieren zu lassen (obwohl ich jahrelang versucht habe, einen Weg zu finden, dies zu vermeiden). Hoffentlich können wir bald experimentieren, um zu sehen, wie es funktioniert.

Meine Wahrnehmung ist, dass die Go-Gemeinschaft/Philosophie lieber abwarten würde, was in der Praxis funktioniert, und es später, wenn es einmal bewiesen ist, übernehmen würde, als die Sprache mit fehlgeschlagenen Experimenten zu überstürzen und zu verschmutzen. Denn wie Sie wiederholt haben, sind all diese abstrakten Behauptungen nicht so konstruktiv (außer vielleicht für PL-Designtheoretiker). Außerdem ist es wahrscheinlich nicht plausibel, ein kohärentes Generikasystem von einem Komitee zu entwerfen.

Es braucht auch gute Anweisungen, wie Dinge verwendet werden sollten und was zu vermeiden ist, und überlegen Sie, wie die Leute es letztendlich verwenden.

Und ich denke, es wird helfen, nicht so viele verschiedene Paradigmen zu mischen, die dem Programmierer in derselben Sprache zur Verfügung stehen. Es ist anscheinend nicht notwendig ( @keean und ich müssen diese Behauptung beweisen). Ich denke, wir schreiben beide der Philosophie zu, dass das Komplexitätsbudget endlich ist und dass das, was Sie aus der PL weglassen , genauso wichtig ist wie die enthaltenen Funktionen.

Das Dokument bezieht jedoch Stellung zu "Problemen, die auf Probleme der realen Welt zurückzuführen sind", da abstrakte und erleichterte Probleme in Foren dazu neigen, in bedeutungsloses Geschwätz zu verfallen, ohne dass Verständnis aufgebaut wird.

Einverstanden. Und es ist auch für alle schwierig, den abstrakten Punkten zu folgen. Der Teufel steckt im Detail und den tatsächlichen Ergebnissen in freier Wildbahn.

Sicher, in der Praxis benötigen Sie diese Art der Optimierung möglicherweise nur für weniger als 1 % der Fälle.

Go hat bereits interface für Generizität, sodass Fälle behandelt werden können, in denen kein parametrischer Polymorphismus für den Typ T für die Instanz der Schnittstelle benötigt wird, die von der Aufrufsite bereitgestellt wird.

Ich glaube, ich habe irgendwo gelesen, vielleicht war es ein Upthread, das Argument, dass die Standardbibliothek von Go tatsächlich unter der Inkonsistenz der optimalen Verwendung der aktuellsten Redewendungen leidet. Ich weiß nicht, ob das stimmt, weil ich noch keine Erfahrung mit Go habe. Der Punkt, den ich mache, ist, dass das gewählte Generika-Paradigma alle Bibliotheken infiziert. Ja, ab sofort können Sie behaupten, dass nur 1 % des Codes dies benötigen würde, da es bereits eine Trägheit in Redewendungen gibt, die die Notwendigkeit von Generika vermeiden.

Du magst Recht haben. Ich habe auch meine Skepsis darüber, wie viel ich eine bestimmte Sprachfunktion verwenden werde. Ich denke, durch Experimentieren werde ich vorgehen, um das herauszufinden. PL-Design ist ein iterativer Prozess, und das Problem besteht darin, gegen die sich entwickelnde Trägheit anzukämpfen, die es schwierig macht, den Prozess zu iterieren. Ich denke also, Rob Pike hat Recht in dem Video, in dem er vorschlägt, Programme zu schreiben, die Code für Programme schreiben (was bedeutet, dass Tools zur Generierung von Werkzeugen und Transpilern geschrieben werden), um zu experimentieren und Ideen zu testen.

Wenn wir zeigen können, dass ein bestimmter Satz von Funktionen in der Praxis (und hoffentlich auch beliebter) denen von Go überlegen ist, dann können wir vielleicht einen Konsens darüber sehen, sie zu Go hinzuzufügen. Ich ermutige andere, ebenfalls experimentelle Systeme zu entwickeln, die auf Go transpilieren.

Können Sie es klarer formulieren und gegebenenfalls in zwei verschiedene Ansätze aufteilen?

Ich schließe mich denjenigen an, die den Versuch entmutigen möchten, ein allzu einfaches Templating-Feature in Go einzubauen und zu behaupten, dass es sich um Generika handelt. IOW, ich denke, ein gut funktionierendes Generika-System, das nicht zu einer schlechten Trägheit wird, ist grundsätzlich unvereinbar mit dem Wunsch nach einem allzu einfachen Design für Generika. Afaik, ein Generika-System braucht ein gut durchdachtes und bewährtes ganzheitliches Design. In Anlehnung an das, was @larsth geschrieben hat , ermutige ich diejenigen mit ernsthaften Vorschlägen, zuerst einen Transpiler zu bauen (oder in einem Fork des gccgo-Frontends zu implementieren) und dann mit dem Vorschlag zu experimentieren, damit wir alle seine Einschränkungen besser verstehen können. Ich wurde ermutigt, oben im Thread zu lesen, dass @ianlancetaylor nicht glaubte, dass eine Verschmutzung durch schlechte Trägheit zu Go hinzugefügt werden würde. Was meine spezielle Beschwerde über den Parametrisierungsvorschlag auf Paketebene betrifft, mein Vorschlag für alle, die ihn vorschlagen, überlegen Sie bitte, ob Sie einen Compiler erstellen, mit dem wir alle spielen können, und dann können wir alle über Beispiele sprechen, was uns gefällt und was nicht. mag es nicht. Sonst reden wir aneinander vorbei, weil ich vielleicht den abstrakt beschriebenen Vorschlag nicht einmal richtig verstehe. Ich muss den Vorschlag nicht verstehen, weil ich nicht verstehe, wie das parametrisierte Paket in einem anderen Paket wiederverwendet werden kann, das ebenfalls parametrisiert ist. IOW, wenn ein Paket Parameter übernimmt, muss es auch andere Pakete mit Parametern instanziieren. Aber es schien, dass der Vorschlag besagte, dass die einzige Möglichkeit, ein parametrisiertes Paket zu instanziieren, mit einem konkreten Typ und nicht mit Typparametern bestand.

Entschuldigung so langatmig. Möchte sicher gehen, dass ich nicht missverstanden werde.

@shelby3 ah, dann habe ich die anfängliche Beschwerde falsch verstanden. Zunächst sollte ich klarstellen, dass die Abschnitte in "Generics Approaches" keine konkreten Vorschläge sind. Es sind Ansätze oder, anders ausgedrückt, größere Designentscheidungen, die man in einem konkreten Generika-Ansatz treffen könnte. Die Gruppierungen sind jedoch stark durch bestehende Implementierungen oder konkrete/informelle Vorschläge motiviert. Außerdem vermute ich, dass auf dieser Liste noch mindestens 5 große Ideen fehlen.

Für den Ansatz "Paketvorlagen" gibt es zwei Varianten davon (siehe die verlinkten Diskussionen im Dokument):

1. "Schnittstellen"-basierte generische Pakete,
2. explizit generische Pakete.

Für 1. erfordert das generische Paket nichts Besonderes -- zum Beispiel würde das aktuelle container/ring für die Spezialisierung nutzbar werden. Stellen Sie sich „Spezialisierung“ hier so vor, dass alle Instanzen der Schnittstelle im Paket durch den konkreten Typ ersetzt werden (und zirkuläre Importe ignoriert werden). Wenn dieses Paket selbst ein anderes Paket spezialisiert, kann es die "Schnittstelle" als Spezialisierung verwenden - daraus folgt, dass diese Verwendung dann ebenfalls spezialisiert wird.

Für 2. können Sie sie auf zwei Arten betrachten. Eine davon ist die rekursive konkrete Spezialisierung bei jedem Import – ähnlich wie beim Templating/Makroing, es gäbe zu keinem Zeitpunkt ein „teilweise angewendetes Paket“. Natürlich kann man auch von der funktionalen Seite her sehen, dass das generische Paket ein Partial mit Parametern ist und man es dann spezialisiert.

Also, ja, Sie können ein parametrisiertes Paket in einem anderen verwenden.

In Anlehnung an das, was @larsth geschrieben hat, ermutige ich diejenigen mit ernsthaften Vorschlägen, zuerst einen Transpiler zu bauen (oder in einem Fork des gccgo-Frontends zu implementieren) und dann mit dem Vorschlag zu experimentieren, damit wir alle seine Einschränkungen besser verstehen können.

Ich weiß, dass dies nicht explizit auf diesen Ansatz ausgerichtet war, aber es gibt 4 verschiedene Prototypen, um die Idee zu testen. Natürlich sind sie keine vollständigen Transpiler, aber sie reichen aus, um einige der Ideen zu testen. dh ich bin mir nicht sicher, ob jemand den Fall "parametrisiertes Paket von einem anderen verwenden" implementiert hat.

Parametrisierte Pakete klingen sehr nach ML-Modulen (und ML-Funktoren sind die Parameter, die andere Pakete sein können). Es gibt zwei Möglichkeiten, wie diese "applikativ" oder "generativ" wirken können. Ein applikativer Funktor ist wie ein Wert oder ein Typ-Alias. Ein generativer Funktor muss konstruiert werden und jede Instanz ist anders. Eine andere Möglichkeit, darüber nachzudenken, ist, dass ein Paket, um anwendbar zu sein, rein sein muss (dh keine veränderlichen Variablen auf Paketebene). Wenn auf Paketebene ein Zustand vorhanden ist, muss dieser generativ sein, da dieser Zustand initialisiert werden muss, und es spielt eine Rolle, welche "Instanz" eines generativen Pakets Sie tatsächlich als Parameter an andere Pakete übergeben, die wiederum generativ sein müssen. Beispielsweise sind Ada-Pakete generativ.

Das Problem mit dem generativen Paketansatz besteht darin, dass er viele Boilerplates erstellt, in denen Sie Pakete mit Parametern instanziieren. Sie können sich Ada-Generika ansehen, um zu sehen, wie das aussieht.

Typklassen vermeiden diesen Textbaustein, indem sie die Typklasse implizit nur basierend auf den in der Funktion verwendeten Typen auswählen. Sie können Typklassen auch als eingeschränktes Überladen mit mehrfachem Dispatch betrachten, wobei die Überladungsauflösung fast immer statisch zur Kompilierzeit erfolgt, mit Ausnahmen für polymorphe Rekursion und existenzielle Typen (die im Wesentlichen Varianten sind, aus denen Sie nicht austreten können, sondern nur verwenden können die Schnittstellen, die die Variante bestätigt).

Ein applikativer Funktor ist wie ein Wert oder ein Typ-Alias. Ein generativer Funktor muss konstruiert werden und jede Instanz ist anders. Eine andere Möglichkeit, darüber nachzudenken, ist, dass ein Paket, um anwendbar zu sein, rein sein muss (dh keine veränderlichen Variablen auf Paketebene). Wenn auf Paketebene ein Zustand vorhanden ist, muss dieser generativ sein, da dieser Zustand initialisiert werden muss, und es spielt eine Rolle, welche "Instanz" eines generativen Pakets Sie tatsächlich als Parameter an andere Pakete übergeben, die wiederum generativ sein müssen. Beispielsweise sind Ada-Pakete generativ.

Vielen Dank für die genaue Terminologie, ich muss überlegen, wie ich diese Ideen in das Dokument integrieren kann.

Außerdem sehe ich keinen Grund, warum Sie keinen "automatischen Typ-Alias ​​für ein generiertes Paket" haben könnten - in gewissem Sinne etwas zwischen "applicative functor" und "generative functor" -Ansatz. Wenn das Paket irgendeine Form von Status enthält, kann es natürlich kompliziert werden, es zu debuggen und zu verstehen.

Das Problem mit dem generativen Paketansatz besteht darin, dass er viele Boilerplates erstellt, in denen Sie Pakete mit Parametern instanziieren. Sie können sich Ada-Generika ansehen, um zu sehen, wie das aussieht.

Soweit ich sehe, würde es weniger Boilerplate als C++-Vorlagen, aber mehr als Typklassen erstellen. Haben Sie ein gutes reales Programm für Ada, das das Problem demonstriert? _(Mit realer Welt meine ich Code, den jemand in der Produktion verwendet/verwendet hat.)_

Klar, schau dir mein Ada Go-Board an: https://github.com/keean/Go-Board-Ada/blob/master/go.adb

Obwohl dies eine ziemlich lockere Definition von Produktion ist, ist der Code optimiert, funktioniert genauso gut wie die C++-Version und ihre Open-Source-Version, und der Algorithmus wurde über mehrere Jahre verfeinert. Sie können sich auch die C++-Version ansehen: https://github.com/keean/Go-Board/blob/master/go.cpp

Dies zeigt (glaube ich), dass Ada-Generika eine sauberere Lösung sind als C++-Templates (aber das ist nicht schwer), andererseits ist es schwierig, den schnellen Zugriff auf die Datenstrukturen in Ada aufgrund der Einschränkungen bei der Rückgabe einer Referenz durchzuführen .

Wenn Sie sich ein Paket-Generika-System für eine imperative Sprache ansehen möchten, ist Ada meiner Meinung nach eines der besten, die Sie sich ansehen sollten. Es ist eine Schande, dass sie sich entschieden haben, auf mehrere Paradigmen umzusteigen und all das OO-Zeug zu Ada hinzuzufügen. Ada ist ein erweitertes Pascal, und Pascal war eine kleine und elegante Sprache. Pascal plus Ada-Generika wäre noch eine recht kleine Sprache gewesen, wäre aber meiner Meinung nach viel besser gewesen. Da sich der Fokus von Ada auf einen OO-Ansatz verlagert hat, scheint es schwierig zu sein, eine gute Dokumentation und Beispiele dafür zu finden, wie man die gleichen Dinge mit Generika macht.

Obwohl ich denke, dass Typklassen einige Vorteile haben, könnte ich mit Generika im Ada-Stil leben, aber es gibt ein paar Probleme, die mich davon abhalten, Ada breiter zu verwenden, ich denke, es setzt Werte/Objekte falsch (ich denke, sehr wenige Sprachen machen das richtig, 'C' ist einer der wenigen), es ist schwierig, mit Zeigern (Zugriffsvariablen) zu arbeiten und sichere Zeigerabstraktionen zu erstellen, und es bietet keine Möglichkeit, Pakete mit Laufzeitpolymorphismus zu verwenden (es bietet ein Objektmodell dafür, aber es fügt ein ganz neues Paradigma hinzu, anstatt zu versuchen, einen Weg zu finden, Laufzeitpolymorphismus mit Paketen zu haben).

Die Lösung für Laufzeitpolymorphismus besteht darin, Pakete erstklassig zu machen, damit Instanzen von Paketsignaturen als Funktionsargumente übergeben werden können. Dies erfordert leider abhängige Typen (siehe die Arbeit an abhängigen Objekttypen für Scala, um das Chaos zu beseitigen, das sie verursacht haben ihr ursprüngliches Typensystem).

Ich denke also, dass Paket-Generika funktionieren können, aber Ada brauchte Jahrzehnte, um mit allen Randfällen fertig zu werden, also würde ich mir ein Produktions-Generika-System ansehen, um zu sehen, welche Verfeinerungen in der produzierten Produktion verwendet werden. Ada ist jedoch immer noch unzureichend, da die Pakete nicht erstklassig sind und nicht in Laufzeitpolymorphismus verwendet werden können, und dies müsste angegangen werden.

@keean schrieb :

Persönlich halte ich die Laufzeitreflexion für eine Fehlfunktion, aber das bin nur ich ... Ich kann erklären, warum, wenn es jemanden interessiert.

Das Löschen von Typen ermöglicht „Theoreme for free“, was praktische Auswirkungen hat. Beschreibbare (und vielleicht sogar lesbare aufgrund transitiver Beziehungen zu imperativem Code?) Laufzeitreflexion macht es unmöglich, referenzielle Transparenz in irgendeinem Code zu garantieren, und daher sind bestimmte Compileroptimierungen nicht möglich und typsichere Monaden sind nicht möglich. Mir ist klar, dass Rust noch nicht einmal eine Unveränderlichkeitsfunktion hat. OTOH, Reflexion ermöglicht andere Optimierungen , die sonst nicht möglich wären, wenn sie nicht statisch typisiert werden könnten.

Ich hatte oben im Thread auch gesagt:

Und genau das würde ein Compiler, der aus einer Obermenge von Go mit hinzugefügten Generika transpiliert, als Go-Code ausgeben. Aber die Verpackung würde nicht auf einer Abgrenzung wie einer Verpackung basieren, da dies die bereits erwähnte Zusammensetzbarkeit verfehlen würde. Der Punkt ist, dass es keine Abkürzung zu einem guten zusammensetzbaren generischen Typsystem gibt. Entweder wir machen es richtig oder wir machen nichts, denn das Hinzufügen eines nicht komponierbaren Hacks, der nicht wirklich generisch ist, wird schließlich eine Clusterfuck-Trägheit von Patchwork, halbherziger Generizität und Unregelmäßigkeit von Eckfällen und Problemumgehungen erzeugen, die Go-Ökosystem-Code machen unverständlich.

@keean schrieb:

[…] Damit ein Paket anwendbar ist, muss es rein sein (d. h. keine veränderlichen Variablen auf Paketebene).

Und es dürfen keine unreinen Funktionen verwendet werden, um unveränderliche Variablen zu initialisieren.

@egonelbre schrieb:

Also, ja, Sie können ein parametrisiertes Paket in einem anderen verwenden.

Was ich anscheinend im Sinn hatte, waren „erstklassige parametrisierte Pakete“ und der entsprechende Laufzeitpolymorphismus (auch bekannt als dynamisch), den @keean später erwähnt hat, weil ich annahm, dass die parametrisierten Pakete anstelle von Typklassen oder OOP vorgeschlagen wurden.

EDIT: aber es gibt zwei mögliche Bedeutungen für „erstklassige“ Module: Module als erstklassige Werte wie in Successor ML und MixML unterschieden von Modulen als erstklassige Werte mit erstklassigen Typen wie in 1ML und der notwendige Kompromiss in Modulrekursion (dh Mischen ) zwischen ihnen.

@keean schrieb:

Die Lösung für Laufzeitpolymorphismus besteht darin, Pakete erstklassig zu machen, damit Instanzen von Paketsignaturen als Funktionsargumente übergeben werden können. Dies erfordert leider abhängige Typen (siehe die Arbeit an abhängigen Objekttypen für Scala, um das Chaos zu beseitigen, das sie verursacht haben ihr ursprüngliches Typensystem).

Was meinst du mit abhängigen Typen? (EDIT: Ich nehme an, er meinte jetzt "nicht-wertabhängige" Typisierung, dh " Funktionen, deren Ergebnistyp vom [Laufzeit?]-Argument ['s Typ] abhängt ") Sicherlich nicht abhängig von den Werten von beispielsweise int -Daten, wie in Idris. Ich denke, Sie beziehen sich auf das abhängige Eingeben (dh Verfolgen) des Typs der Werte, die instanziierte Modulinstanzen in der Aufrufhierarchie darstellen, damit solche polymorphen Funktionen zur Kompilierzeit monomorphisiert werden können? Tritt der Laufzeitpolymorphismus ein, weil solche monomorphisierten Typen der existenzielle Typ sind, der für dynamische Typen gebunden ist? F-ing-Module zeigten, dass „abhängige“ Typen nicht unbedingt erforderlich sind, um ML-Module im System F _ω zu modellieren. Habe ich zu stark vereinfacht, wenn ich annehme, dass @rossberg das Typisierungsmodell neu formuliert hat, um alle Monomorphisierungsanforderungen zu entfernen?

Das Problem mit dem generativen Paketansatz ist, dass er viele Boilerplates erzeugt […]
Typklassen vermeiden diesen Textbaustein, indem sie die Typklasse implizit nur basierend auf den in der Funktion verwendeten Typen auswählen.

Gibt es nicht auch eine Boilerplate mit applikativen ML-Funktoren? Es gibt keine bekannte Vereinheitlichung von Typklassen und ML-Funktoren (Modulen), die die Kürze beibehält, ohne Beschränkungen einzuführen , die notwendig sind, um die inhärente Anti-Modularität des globalen Eindeutigkeitskriteriums von Typklassen-Implementierungsinstanzen zu verhindern (vgl. auch ).

Typklassen können jeden Typ nur auf eine Weise implementieren und benötigen ansonsten newtype Wrapper-Boilerplate, um die Einschränkung zu überwinden. Hier ist ein weiteres Beispiel für mehrere Möglichkeiten, einen Algorithmus zu implementieren. Afaics, @keean hat diese Einschränkung in seinem Typeclass-Sortierungsbeispiel umgangen, indem er die implizite Auswahl mit einem explizit ausgewählten Relation überschrieben hat, indem er data -Typen verwendet, um verschiedene Beziehungen generisch für den Werttyp zu benennen, aber ich bezweifle ob solche Taktiken allgemein für alle Varianten der Modularität gelten. Eine allgemeinere Lösung (die bei der Verbesserung des Modularitätsproblems der globalen Eindeutigkeit möglicherweise in Kombination mit einer Waisenbeschränkung als Verbesserung der vorgeschlagenen Versionierung für die Auflösung von Waisen helfen kann, indem eine Nicht-Standardeinstellung für Implementierungen verwendet wird, die verwaist sein könnten) könnte jedoch darin bestehen, eine zu haben interface , der, wenn er nicht angegeben ist, standardmäßig die normale implizite Übereinstimmung verwendet, aber wenn er angegeben ist (oder wenn er nicht angegeben ist, mit keinem anderen übereinstimmt ² ), dann die Implementierung auswählt, die denselben Wert hat in seiner durch Kommas getrennten Liste benutzerdefinierter Werte (dies ist also ein allgemeineres, modulares Matching als das Benennen einer bestimmten implement -Instanz). Die durch Kommas getrennte Liste dient dazu, dass eine Implementierung in mehr als einem Freiheitsgrad unterschieden werden kann, z. B. wenn sie zwei orthogonale Spezialisierungen hat. Das gewünschte nicht standardmäßige spezialisierte kann entweder an der Funktionsdeklaration oder an der Aufrufstelle angegeben werden. Auf der Aufrufseite, zB f<non-default>(…) .

Warum brauchen wir also parametrisierte Module, wenn wir Typklassen haben? Afaics nur für (← wichtiger Link zum Anklicken) Substitution, da die Wiederverwendung von Typklassen für diese Zwecke nicht gut passt, da wir beispielsweise möchten, dass ein Paketmodul mehrere Dateien umfassen kann und wir in der Lage sein möchten, den Inhalt von implizit zu öffnen das Modul ohne zusätzliche Textbausteine ​​in den Anwendungsbereich aufnehmen . Daher ist es vielleicht ein vernünftiger erster Schritt, mit einer Paketparametrisierung nur _syntaktisch_ nur mit Substitution (nicht erstklassig) fortzufahren, die die Generizität auf Modulebene ansprechen kann, während sie offen für Kompatibilität mit und Nichtüberschneidung von Funktionalität bleibt, wenn Typklassen später für Funktionsebene hinzugefügt werden Generizität. Es gibt Makros beispielsweise typisiert sind oder nur eine syntaktische (auch als „Präprozessor“ bezeichnete) Substitution sind. Wenn sie typisiert sind, duplizieren Module die Funktionalität von Typklassen, was sowohl vom Standpunkt der Minimierung der sich überschneidenden Paradigmen/Konzepte der PL als auch von möglichen Eckfällen aufgrund von Wechselwirkungen der Überlappung (z. B. beim Versuch , sowohl ML-Funktoren als auch Typklassen anzubieten) unerwünscht ist ). Typisierte Module sind modularer, da Änderungen an gekapselten Implementierungen innerhalb des Moduls, die die exportierten Signaturen nicht ändern, nicht dazu führen können, dass Verbraucher des Moduls inkompatibel werden (mit Ausnahme des oben erwähnten Anti-Modularitätsproblems von Typklassen überlappenden Implementierungsinstanzen). Ich bin daran interessiert, die Gedanken von @keean dazu zu lesen.

[…] mit Ausnahmen für polymorphe Rekursion und existentielle Typen (bei denen es sich im Wesentlichen um Varianten handelt, aus denen Sie nicht austreten können, Sie können nur die Schnittstellen verwenden, die die Variante bestätigt).

Um anderen Lesern zu helfen. Unter „polymorpher Rekursion“ versteht man meiner Meinung nach höherrangige Typen, z. B. parametrisierte Callbacks, die zur Laufzeit gesetzt werden, wobei der Compiler den Rumpf der Callback-Funktion nicht monomorphisieren kann, weil er zur Kompilierzeit nicht bekannt ist. Die existenziellen Typen sind, wie ich bereits erwähnt habe, äquivalent zu den Trait-Objekten von Rust, die eine Möglichkeit darstellen, heterogene Container mit einer späteren Bindung im Ausdrucksproblem als die virtuelle Vererbung class zu erreichen, aber nicht so offen für Erweiterungen im Ausdruck Problem als Vereinigungen mit unveränderlichen Datenstrukturen oder Kopieren von ³ , die einen Leistungsaufwand von O(log n) haben.

¹ _{Was HKT im obigen Beispiel nicht erfordert, da SET nicht erfordert, dass der Typ elem ein Typparameter des generischen Typs von set ist, dh es ist nicht set<elem> .}

² _{Wenn jedoch mehr als eine Nicht-Standardimplementierung und keine Standardimplementierung vorhanden wäre, wäre die Auswahl mehrdeutig, sodass der Compiler einen Fehler generieren sollte.}

³ _{Beachten Sie, dass das Mutieren mit unveränderlichen Datenstrukturen nicht unbedingt das Kopieren der gesamten Datenstruktur erfordert, wenn die Datenstruktur intelligent genug ist, um den Verlauf wie eine einfach verknüpfte Liste zu isolieren.}

Die Implementierung func pick(a CollectionOfT, count uint) []T wäre eine gute Beispielanwendung für Generika (von 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) {

Der Interface{}-Ansatz hier ist kompliziert.

Ich habe einige Male zu diesem Thema kommentiert, dass eines der Hauptprobleme des C++-Template-Ansatzes darin besteht, dass er sich auf die Auflösung von Überladungen als Mechanismus für die Metaprogrammierung zur Kompilierzeit verlässt.

Es scheint, dass Herb Sutter zu demselben Schluss gekommen ist: Es gibt jetzt einen interessanten Vorschlag für die Kompilierzeit-Programmierung in C++ .

Es hat einige Elemente sowohl mit dem Paket Go reflect als auch mit meinem früheren Vorschlag für Funktionen zur Kompilierzeit in Go gemeinsam.

Hallo.
Ich habe einen Vorschlag für Generika mit Einschränkungen für Go geschrieben. Sie können es hier lesen. Vielleicht kann es als Dokument von 15292 hinzugefügt werden. Es handelt hauptsächlich von Einschränkungen und liest sich als Ergänzung zu Taylors Typparametern in Go .
Es ist als Beispiel für eine praktikable (glaube ich) Möglichkeit gedacht, "typsichere" Generika in Go zu erstellen - hoffentlich kann es etwas zu dieser Diskussion beitragen.
Bitte beachten Sie, dass ich, obwohl ich (den größten Teil) dieses sehr langen Threads gelesen habe, nicht allen darin enthaltenen Links gefolgt bin, sodass andere möglicherweise ähnliche Vorschläge gemacht haben. Wenn das der Fall ist, entschuldige ich mich.

Br. Chr.

Syntax bikeshedding:

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

könnte sein

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

was eher wie Go to me aussieht. :-)

Hier mehrere Elemente.

Eine Sache ist, : durch _ und # durch ... zu ersetzen.
Ich nehme an, Sie könnten das tun, wenn es bevorzugt wird.

Eine andere Sache ist das Ersetzen constraint[T] Array durch type[T] Array constraint .
Das scheint darauf hinzudeuten, dass Einschränkungen Typen sind, was ich nicht für richtig halte. Formal ist eine Einschränkung ein _Prädikat_ auf der Menge aller Typen, dh. eine Zuordnung von der Menge der Typen zur Menge { true , false }.
Oder wenn Sie es vorziehen, können Sie sich eine Einschränkung einfach als _eine Reihe von_ Typen vorstellen.
Es ist nicht _ein_ Typ.

Br. Chr.

Warum ist das constraint nicht nur ein interface ?

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

Eine Schnittstelle wäre als Einschränkung mit dem folgenden Vorschlag etwas nützlicher: #23796, was wiederum auch dem Vorschlag selbst einen gewissen Wert verleihen würde.

Wenn der Vorschlag für Summentypen in irgendeiner Form akzeptiert wird (#19412), dann sollten diese verwendet werden, um den Typ einzuschränken.

Obwohl ich das Schlüsselwort Constraint glaube, sollte etwas Ähnliches hinzugefügt werden, um große Constraints nicht zu wiederholen und Fehler aufgrund von Zerstreutheit zu vermeiden.

Schließlich denke ich, dass für den Teil des Fahrradabwurfs Einschränkungen am Ende einer Definition aufgeführt werden sollten, um eine Überfüllung zu vermeiden (Rost scheint hier eine gute Idee zu haben):

// 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 : Ich denke, es ist ein großer Vorteil für go, Schnittstellen implizit statt explizit zu implementieren. Der Vorschlag von @surlykke in diesem Kommentar ist meiner Meinung nach viel näher an der anderen Go-Syntax im Geiste.

@surlykke Ich entschuldige mich, wenn der Vorschlag die Antwort auf eine dieser Fragen enthält.

Eine Verwendung von Generika besteht darin, eingebaute Stilfunktionen zuzulassen. Wie würden Sie damit Len auf Anwendungsebene implementieren? Das Speicherlayout ist für jede zulässige Eingabe unterschiedlich, also wie ist das besser als eine Schnittstelle?

Das zuvor beschriebene „Pick“ hat ein ähnliches Problem, bei dem die Indizierung in eine Map und die Indizierung in einen Slice unterschiedlich sind. Wenn im Kartenfall zuerst eine Konvertierung in Slice erfolgte, kann derselbe Kommissioniercode verwendet werden, aber wie wird dies durchgeführt?

Sammlungen ist eine weitere Verwendung:

// 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”})

Für den Sammlungstyp bin ich nicht überzeugt, dass dies ein großer Gewinn gegenüber Go 1-Generika ist, da es Kompromisse bei der Lesbarkeit gibt.

Ich stimme zu, dass Typparameter irgendeine Form von Einschränkungen haben müssen. Andernfalls werden wir die Fehler von C++-Vorlagen wiederholen. Die Frage ist, wie aussagekräftig sollten die Einschränkungen sein?

An einem Ende könnten wir einfach Schnittstellen verwenden. Aber wie Sie betonen, können viele nützliche Muster auf diese Weise nicht erfasst werden.

Dann gibt es Ihre Idee und ähnliche, die versuchen, eine Reihe nützlicher Einschränkungen herauszuarbeiten und eine neue Syntax für deren Ausdruck bereitzustellen. Abgesehen von dem Problem, noch mehr Syntax hinzuzufügen, ist nicht klar, wo man aufhören soll. Wie Sie betonen, erfasst Ihr Vorschlag viele Muster, aber keineswegs alle.

Das andere Extrem ist die Idee, die ich in diesem Dokument vorschlage. Es verwendet Go-Code selbst als Constraint-Sprache. Auf diese Weise können Sie praktisch jede Einschränkung erfassen, und es ist keine neue Syntax erforderlich.

@jba
Es ist ein bisschen ausführlich. Wenn Go eine Lambda-Syntax hätte, wäre es vielleicht etwas schmackhafter. Andererseits scheint das größte Problem, das es zu lösen versucht, zu prüfen, ob ein Typ einen Operator irgendeiner Art unterstützt. Es könnte einfacher sein, wenn Go nur vordefinierte Schnittstellen für verschiedene Operatoren hätte:

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)
}

oder so ähnlich.

Wenn das Problem beim Erweitern von Builtins liegt, liegt das Problem möglicherweise in der Art und Weise, wie die Sprache Adaptertypen erstellt. Ist zum Beispiel das mit sort.Interface verbundene Aufblähen nicht der ganze Grund hinter https://github.com/golang/go/issues/16721 und sort.Slice?
Wenn Sie sich https://github.com/golang/go/issues/21670#issuecomment -325739411 ansehen, könnte die Idee von @Sajmani , Schnittstellenliterale zu haben, die Zutat sein, die erforderlich ist, damit Typparameter problemlos mit integrierten Funktionen arbeiten können.
Schauen Sie sich die folgende Definition von Iterator an:

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

Wenn print eine Funktion ist, die einfach über eine Liste iteriert und ihren Inhalt ausgibt, dann verwendet das folgende Beispiel Schnittstellenliterale, um eine zufriedenstellende Schnittstelle für print zu erstellen.

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))
}

Dies kann man bereits tun, wenn sie Typen global deklarieren, deren einzige Aufgabe es ist, eine Schnittstelle zu erfüllen. Diese Umwandlung von einer Funktion in eine Methode macht es jedoch einfacher, Schnittstellen (und damit "Einschränkungen") zu erfüllen. Wir verunreinigen Top-Level-Deklarationen nicht mit einfachen Adaptern (wie „widgetsByName“ beim Sortieren).
Benutzerdefinierte Typen können diese Funktion offensichtlich ebenfalls nutzen, wie dieses LinkedList-Beispiel zeigt:

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 : Einschränkungen, wie ich sie beschrieben habe, sind ausdrucksstärker als Schnittstellen (Felder, Operatoren). Ich habe kurz darüber nachgedacht, Schnittstellen zu erweitern, anstatt Beschränkungen einzuführen, aber ich denke, das wäre eine viel zu aufdringliche Änderung an einem bestehenden Element von Go.

@pciet Ich bin mir nicht ganz sicher, was Sie mit "Anwendungsebene" meinen. Go hat eine eingebaute len -Funktion, die auf Arrays, Zeiger auf Arrays, Slices, Strings und Kanäle angewendet werden kann. Wenn also in meinem Vorschlag ein Typparameter darauf beschränkt ist, einen von diesen als zugrunde liegenden Typ zu haben , len kann darauf angewendet werden.

@pciet Über Ihr Beispiel mit Comparable Einschränkung/Schnittstelle. Beachten Sie Folgendes, wenn Sie (die Schnittstellenvariante) definieren:

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

Dann können Sie alles, was Comparable implementiert, in Set . Vergleichen Sie das mit:

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

wo Sie nur Werte vom Typ Foo in FooSet können. Das ist stärkere Typensicherheit.

@urandom Nochmal, ich bin kein Fan von:

type MyConstraint constraint {....}

da ich nicht glaube, dass eine Einschränkung ein Typ ist. Außerdem würde ich definitiv nicht zulassen:

var myVar MyConstraint

was für mich keinen sinn macht. Ein weiterer Hinweis darauf, dass Constraints keine Typen sind.

@urandom On bikeshedding: Ich glaube, Einschränkungen sollten direkt neben den Typparametern deklariert werden. Stellen Sie sich eine gewöhnliche Funktion vor, die wie folgt definiert ist:

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

Das konnte man nicht von links nach rechts lesen. Stattdessen würden Sie zuerst func MyFunc(i) lesen, um festzustellen, dass es sich um eine Funktionsdefinition handelt. Dann müssten Sie zum Ende springen, um herauszufinden, was i ist, und dann zurück zum Funktionskörper. Nicht ideal, IMO. Und ich sehe nicht, wie generische Definitionen anders sein sollten.
Aber offensichtlich ist diese Diskussion orthogonal zu der darüber, ob Go Einschränkungen oder Generika haben sollte.

@surlykke
Ich finde es gut, dass es kein Typ ist. Das Wichtigste ist, dass sie einen Namen haben, damit von mehreren Typen auf sie verwiesen werden kann.

Für Funktionen wäre es, wenn wir der Rust-Syntax folgen:

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

Es werden also Dinge wie der Name der Funktion oder ihre Parameter nicht ausgeblendet, und Sie müssten nicht bis zum Ende des Funktionskörpers gehen, um zu sehen, was die Einschränkungen für die generischen Typen sind

@surlykke für die Nachwelt, könnten Sie herausfinden, wo Ihr Vorschlag hinzugefügt werden könnte:
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

Es ist ein großartiger Ort, um alle Vorschläge zu "kompilieren".

Eine weitere Frage, die ich Ihnen allen stelle, ist, wie man mit der Spezialisierung verschiedener Instanziierungen eines generischen Typs umgehen würde. Im Type-Params- Vorschlag besteht die Möglichkeit darin, dieselbe Template-Funktion für jeden instanziierten Typ zu generieren und den Typparameter durch den Typnamen zu ersetzen. Um separate Funktionalität für verschiedene Typen zu haben, führen Sie einen Typwechsel am Typparameter durch.

Kann man davon ausgehen, dass der Compiler, wenn er einen Typwechsel für einen Typparameter sieht, für jede Behauptung eine separate Implementierung generieren darf? Oder ist das eine zu aufwendige Optimierung, da verschachtelte Typparameter in den behaupteten Strukturen einen parametrischen Aspekt für die Codegenerierung erzeugen können?

Da wir wissen, dass diese Deklarationen zur Kompilierzeit generiert werden, verursacht ein Typwechsel im Vorschlag für Funktionen zur Kompilierzeit keine Laufzeitkosten.

Ein praktisches Szenario: Wenn wir einen Fall des math/bits -Pakets betrachten, würde das Durchführen einer Typ-Assertion zum Aufrufen OnesCount für jedes uintXX den Punkt einer effizienten Bit-Manipulationsbibliothek übertreffen. Wenn jedoch die Typ-Assertionen in das Folgende umgewandelt wurden

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...
    }
}

Ein Anruf bei

var x uint8 = 255
bits.OnesCount(x)

würde dann die folgende generierte Funktion aufrufen (Name ist hier nicht wichtig):

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

@jba Das ist ein interessanter Vorschlag, aber für mich unterstreicht er hauptsächlich die Tatsache, dass die Definition der parametrischen Funktion selbst normalerweise ausreicht, um ihre Einschränkungen zu definieren.

Wenn Sie „in einer Funktion verwendete Operatoren“ als Einschränkungen verwenden, welchen Vorteil bringt es Ihnen dann, eine zweite Funktion zu schreiben, die eine Teilmenge der in der ersten verwendeten Operatoren enthält?

@bcmills Eine davon ist eine Spezifikation und die andere die Implementierung. Es ist der gleiche Vorteil wie beim statischen Schreiben: Sie können Fehler früher abfangen.

Wenn es sich bei der Implementierung um die Spezifikation handelt, à la C++-Vorlagen, kann jede Änderung an der Implementierung möglicherweise abhängige Elemente beschädigen. Dies wird möglicherweise erst viel später entdeckt, wenn die Abhängigen neu kompilieren und die Entdecker keinen Kontext haben, um die Fehlermeldung zu verstehen. Mit der Spezifikation in derselben Verpackung können Sie den Bruch lokal erkennen.

@mandolyte Ich bin mir nicht ganz sicher, wo ich es hinzufügen soll - vielleicht ein Absatz unter "Generika-Ansätze" mit dem Namen "Generika mit Einschränkungen"?
Das Dokument scheint nicht viel über das Einschränken von Typparametern zu enthalten. Wenn Sie also einen Absatz hinzufügen, in dem mein Vorschlag erwähnt wird, könnten dort auch andere Ansätze für Einschränkungen aufgeführt werden.

@surlykke Der allgemeine Ansatz für das Dokument besteht darin, eine Änderung vorzunehmen, die sich richtig anfühlt, und ich werde versuchen, sie zu akzeptieren, zu integrieren und mit dem Rest des Dokuments zu organisieren. Ich habe hier einen Abschnitt hinzugefügt. Fühlen Sie sich frei, Dinge hinzuzufügen, die ich verpasst habe.

@egonelbre Das ist sehr schön. Danke!

@jba
Ich mag deinen Vorschlag, aber ich denke, er ist viel zu schwer für Golang. Es erinnert mich sehr an Templates in C++. Das Hauptproblem ist meiner Meinung nach, dass man damit wirklich komplexen Code schreiben kann.
Zu entscheiden, ob sich zwei generische Schnittstelleninstanzen überschneiden, weil sich der eingeschränkte Satz von Typen überschneidet, wäre eine schwierige Aufgabe, die langsamere Kompilierzeiten verursacht. Dasselbe gilt für die Codegenerierung.

Ich denke, dass die vorgeschlagenen Einschränkungen für unterwegs leichter sind. Soweit ich gehört habe, könnten Einschränkungen, auch Typklassen genannt, orthogonal zum Typsystem einer Sprache implementiert werden.

Ich muss ausdrücklich zustimmen, dass wir nicht mit impliziten Einschränkungen aus dem Körper der Funktion gehen sollten. Sie werden weithin als eine der wichtigsten Fehlfunktionen von C++-Vorlagen angesehen:

• Die Einschränkungen sind nicht leicht sichtbar. Während godoc theoretisch alle Einschränkungen in der Dokumentation aufzählen könnte, sind sie im Quellcode nur implizit sichtbar.
• Aus diesem Grund ist es möglich, versehentlich eine zusätzliche Einschränkung einzufügen, die nur sichtbar ist, wenn Sie versuchen, die Funktion auf eine unerwartete Weise zu verwenden. Indem eine explizite Spezifikation der Beschränkungen gefordert wird, muss der Programmierer genau wissen, welche Beschränkungen er einführt.
• Es trifft die Entscheidung darüber, welche Arten von Beschränkungen erlaubt sind, viel eher ad-hoc. Darf ich zum Beispiel die folgende Funktion definieren? Was sind hier die tatsächlichen Einschränkungen für T, U und V? Wenn wir vom Programmierer verlangen, Einschränkungen explizit anzugeben, dann sind wir konservativ in der Art von Einschränkungen, die wir zulassen (und uns das langsam und bewusst erweitern lassen). Wenn wir versuchen, trotzdem konservativ zu sein, wie geben wir dann eine Fehlermeldung für eine solche Funktion aus? "Fehler: T kann uv() nicht zuweisen, da es eine unzulässige Einschränkung auferlegt"?

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

• Das Aufrufen generischer Funktionen in anderen generischen Funktionen verschlimmert die oben genannten Situationen, da Sie jetzt alle Einschränkungen der aufgerufenen Personen durchsehen müssen, um die Einschränkungen der Funktion zu verstehen, die Sie schreiben oder lesen.
• Das Debuggen kann sehr schwierig sein, da Fehlermeldungen entweder nicht genügend Informationen liefern müssen, um die Quelle der Einschränkung zu finden, oder interne Details der Funktion preisgeben müssen. Wenn zum Beispiel F eine Anforderung an einen Typ T hat und der Autor von F versucht herauszufinden, woher diese Anforderung stammt, möchte er, dass der Compiler dies tut Machen Sie sie darauf aufmerksam, welche Anweisung genau zu der Einschränkung führt (insbesondere, wenn sie von einem generischen Aufgerufenen stammt). Aber ein Benutzer von F möchte diese Informationen nicht, und tatsächlich, wenn sie in den Fehlermeldungen enthalten sind, dann geben wir Implementierungsdetails von F in Fehlermeldungen von seinen Benutzern preis, was sind eine schreckliche Benutzererfahrung.

@alercah

Darf ich zum Beispiel die folgende Funktion definieren?

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

Nein. u.v(V) ist ein Syntaxfehler, da V ein Typ ist und die Variable t nicht verwendet wird.

Sie könnten jedoch diese Funktion definieren, die möglicherweise die von Ihnen beabsichtigte ist:

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

Was sind hier die tatsächlichen Einschränkungen für T, U und V?

• Der Typ V ist uneingeschränkt.
• Der Typ U muss eine Methode v haben, die einen einzelnen Parameter oder Varargs eines Typs akzeptiert, der von V zuweisbar ist, da u.v mit einem einzigen Argument aufgerufen wird vom Typ V .
  
  
  
  • U.v könnte ein Feld vom Funktionstyp sein, aber das sollte wohl eine Methode implizieren; siehe #23796.
  
  
• Der von U.v zurückgegebene Typ muss numerisch sein, da ihm die Konstante 1 hinzugefügt wird.
• Der Rückgabetyp von U.v muss T zuweisbar sein, da u.v(…) + 1 einer Variablen vom Typ T zugewiesen wird.
• Der Typ T muss numerisch sein, da der Rückgabetyp von U.v numerisch ist und T werden kann.

(Nebenbei: Sie könnten argumentieren, dass U und V die Einschränkung „kopierbar“ haben sollten, da Argumente dieser Typen als Wert übergeben werden, aber das vorhandene, nicht generische Typsystem erzwingt dies nicht diese Einschränkung auch nicht. Das ist eine Angelegenheit für einen separaten Vorschlag.)

Wenn wir vom Programmierer verlangen, Einschränkungen explizit anzugeben, dann sind wir konservativ in der Art von Einschränkungen, die wir zulassen (und uns das langsam und bewusst erweitern lassen).

Ja, das stimmt, aber das Weglassen einer Einschränkung wäre ein schwerwiegender Fehler, unabhängig davon, ob diese Einschränkungen implizit sind oder nicht. Meiner Meinung nach besteht die wichtigere Rolle von Einschränkungen darin, Mehrdeutigkeiten aufzulösen. Beispielsweise muss der Compiler in den obigen Einschränkungen darauf vorbereitet sein, u.v entweder als Einzelargument- oder als variadische Methode zu instanziieren.

Die interessanteste Mehrdeutigkeit tritt bei Literalen auf, wo wir zwischen Strukturtypen und zusammengesetzten Typen unterscheiden müssen:

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

Wenn wir versuchen, trotzdem konservativ zu sein, wie geben wir dann eine Fehlermeldung für eine solche Funktion aus? "Fehler: T kann uv() nicht zuweisen, da es eine unzulässige Einschränkung auferlegt"?

Ich bin mir nicht ganz sicher, was Sie fragen, da ich für dieses Beispiel keine widersprüchlichen Einschränkungen sehe. Was meinst du mit einer "illegalen Beschränkung"?

Das Debuggen kann sehr schwierig sein, da Fehlermeldungen entweder nicht genügend Informationen liefern müssen, um die Quelle der Einschränkung zu finden, oder interne Details der Funktion preisgeben müssen.

Nicht jede relevante Einschränkung kann durch das Typsystem ausgedrückt werden (siehe auch https://github.com/golang/go/issues/22876#issuecomment-347035323). Einige Beschränkungen werden durch Laufzeitpaniken erzwungen; einige werden vom Renndetektor erzwungen; die gefährlichsten Engpässe werden lediglich dokumentiert und gar nicht erkannt.

Alle diese „internen Details“ lassen bis zu einem gewissen Grad nach. (Siehe auch https://xkcd.com/1172/.)

Wenn zum Beispiel […] der Autor von F herauszufinden versucht, woher diese Anforderung stammt, möchte er, dass der Compiler ihn darauf hinweist, welche Anweisung genau zu der Einschränkung führt (insbesondere, wenn sie von einem generischen Aufgerufenen stammt). Aber ein Benutzer von F möchte diese Informationen nicht[.]

Könnte sein? Auf diese Weise verwenden API-Autoren Typannotationen in typabgeleiteten Sprachen wie Haskell und ML, aber es führt auch im Allgemeinen in ein Kaninchenloch tief parametrischer Typen („höherer Ordnung“).

Angenommen, Sie haben diese Funktion:

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

Wie drücken Sie die expliziten Einschränkungen für den Typ Arg aus? Sie hängen von der spezifischen Instanziierung von F ab. Diese Art von Abhängigkeit scheint in vielen der jüngsten Vorschläge für Beschränkungen zu fehlen.

Nein. uv(V) ist ein Syntaxfehler, da V ein Typ ist und die Variable t nicht verwendet wird.

Sie könnten jedoch diese Funktion definieren, die möglicherweise die von Ihnen beabsichtigte ist:

Ja, das war die Absicht, entschuldige bitte.

Der Typ T muss numerisch sein, da der Rückgabetyp von U.v numerisch ist und T werden kann.

Sollten wir dies wirklich als Einschränkung betrachten? Es ist aus den anderen Einschränkungen ableitbar, aber ist es mehr oder weniger sinnvoll, dies als eindeutige Einschränkung zu bezeichnen? Implizite Constraints stellen diese Frage auf eine Weise, wie es explizite Constraints nicht tun.

Ja, das stimmt, aber das Weglassen einer Einschränkung wäre ein schwerwiegender Fehler, unabhängig davon, ob diese Einschränkungen implizit sind oder nicht. Meiner Meinung nach besteht die wichtigere Rolle von Einschränkungen darin, Mehrdeutigkeiten aufzulösen. Beispielsweise muss der Compiler in den obigen Einschränkungen darauf vorbereitet sein, uv entweder als Einzelargument- oder als Variadic-Methode zu instanziieren.

Ich meinte "Einschränkungen, die wir zulassen" wie in der Sprache. Mit expliziten Beschränkungen ist es für uns viel einfacher zu entscheiden, welche Art von Beschränkungen wir Benutzern erlauben zu schreiben, anstatt nur zu sagen, dass die Beschränkung „was auch immer Dinge kompilieren lässt“ ist. Zum Beispiel beinhaltet mein obiges Beispiel Foo tatsächlich einen impliziten zusätzlichen Typ getrennt von T , U oder V , da wir den Rückgabetyp von berücksichtigen müssen u.v . Auf diesen Typ wird in der Deklaration f in keiner Weise ausdrücklich verwiesen; die Eigenschaften, die es haben muss, sind völlig implizit. Sind wir ebenfalls bereit, Typen mit höherem Rang ( forall ) zuzulassen? Ich kann mir auf Anhieb kein Beispiel einfallen lassen, aber ich kann mich auch nicht davon überzeugen, dass Sie nicht implizit eine Typbindung mit höherem Rang schreiben können.

Ein weiteres Beispiel ist, ob wir zulassen sollten, dass eine Funktion eine überladene Syntax nutzt. Wenn eine implizit eingeschränkte Funktion for i := range t für einige t des generischen Typs T ausführt, funktioniert die Syntax, wenn T irgendein Array, Slice, Kanal, oder Karte. Aber die Semantik ist ganz anders, besonders wenn T ein Kanaltyp ist. Wenn beispielsweise t == nil (was passieren kann, solange T ein Array ist), dann macht die Iteration entweder nichts, da es keine Elemente in einem Null-Slice oder einer Null-Map gibt, oder blockiert für immer denn genau das tun Empfänger auf nil Kanälen. Dies ist eine große Fußwaffe, die darauf wartet, passiert zu werden. Ähnlich verhält es sich mit m[i] = ... ; Wenn ich beabsichtige, dass m eine Karte ist, muss ich mich davor hüten, dass es tatsächlich ein Slice ist, da der Code sonst bei einer Zuweisung außerhalb des Bereichs in Panik geraten könnte.

Tatsächlich denke ich, dass dies ein weiteres Argument gegen implizite Beschränkungen ist: API-Autoren könnten künstliche Anweisungen schreiben, nur um Beschränkungen hinzuzufügen. Zum Beispiel verhindert for _, _ := range t { break } einen Kanal, lässt aber weiterhin Maps, Slices und Arrays zu; x = append(x) erzwingt x den Slice-Typ. var _ = make(T, 0) erlaubt Slices, Maps und Channels, aber keine Arrays. Es wird ein Rezeptbuch zum impliziten Hinzufügen von Einschränkungen geben, damit jemand Ihre Funktion nicht mit einem Typ aufrufen kann, für den Sie keinen korrekten Code geschrieben haben. Ich kann mir nicht einmal vorstellen, Code zu schreiben, der nur für Kartentypen kompiliert, es sei denn, ich kenne auch den Schlüsseltyp. Und ich denke nicht, dass das überhaupt hypothetisch ist; Maps und Slices verhalten sich für die meisten Anwendungen recht unterschiedlich

Ich bin mir nicht ganz sicher, was Sie fragen, da ich für dieses Beispiel keine widersprüchlichen Einschränkungen sehe. Was meinst du mit einer "illegalen Beschränkung"?

Ich meine eine Einschränkung, die von der Sprache nicht zugelassen wird, z. B. wenn die Sprache entscheidet, höherrangige Einschränkungen zu verbieten.

Nicht jede relevante Einschränkung kann durch das Typsystem ausgedrückt werden (siehe auch #22876 (Kommentar)). Einige Beschränkungen werden durch Laufzeitpaniken erzwungen; einige werden vom Renndetektor erzwungen; die gefährlichsten Engpässe werden lediglich dokumentiert und gar nicht erkannt.

Alle diese „internen Details“ lassen bis zu einem gewissen Grad nach. (Siehe auch https://xkcd.com/1172/.)

Ich verstehe nicht wirklich, wie #22876 dazu kommt; das versucht, das Typensystem zu verwenden, um eine andere Art von Einschränkung auszudrücken. Es wird immer wahr sein, dass wir einige Beschränkungen für Werte oder Programme nicht ausdrücken können, selbst mit einem Typensystem beliebiger Komplexität. Aber wir sprechen hier nur über Einschränkungen für Typen . Der Compiler muss in der Lage sein, die Frage „Kann ich dieses Generikum mit dem Typ T instanziieren?“ zu beantworten. was bedeutet, dass es die Beschränkungen verstehen muss, ob sie implizit oder explizit sind. (Beachten Sie, dass einige Sprachen, wie C++ und Rust, diese Frage im Allgemeinen nicht entscheiden können, da sie von willkürlicher Berechnung abhängen kann und somit zum Halteproblem führt, aber sie drücken immer noch die Einschränkungen aus, die erfüllt werden müssen.)

Was ich meine, ist eher "Welche Fehlermeldung soll das folgende Beispiel geben?"

func [U] DirectlyConstrained(U t) {
    t.DoSomething();
}
func [T] IndirectlyConstrained(T t) {
    DirectlyConstrainted(t);
}
func Illegal() {
    IndirectlyConstrained(4);
}

Wir können Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() sagen. Diese Fehlermeldung ist hilfreich für einen Benutzer von IndirectlyConstrained , da sie die fehlenden Einschränkungen deutlich macht. Aber es liefert niemandem, der zu debuggen versucht, warum IndirectlyConstrained diese Einschränkung hat, was ein großes Usability-Problem ist, wenn es sich um eine große Funktion handelt. Wir könnten Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N hinzufügen, aber jetzt geben wir Details zur Implementierung von IndirectlyConstrained preis. Darüber hinaus haben wir nicht erklärt, warum IndirectlyConstrained die Einschränkung hat, also fügen wir ein weiteres Note: this constraint exists on U because DirectlyConstrained calls t.DoSomething() on line M hinzu? Was ist, wenn die implizite Einschränkung von einem Aufgerufenen vier Ebenen weiter unten im Aufrufstapel stammt?

Wie formatieren wir außerdem diese Fehlermeldungen für Typen, die nicht explizit als Parameter aufgeführt sind? ZB wenn im obigen Beispiel IndirectlyConstrained DirectlyConstrained(t.U()) $ aufruft. Wie beziehen wir uns überhaupt auf den Typ? In diesem Fall könnten wir the type of t.U() sagen, aber der Wert ist nicht unbedingt das Ergebnis eines einzelnen Ausdrucks; es könnte über mehrere Anweisungen aufgebaut werden. Dann müssten wir entweder einen Ausdruck mit den richtigen Typen synthetisieren, um die Fehlermeldung einzufügen, einen, der nie im Code erscheint, oder wir müssten einen anderen Weg finden, darauf zu verweisen, der für die weniger klar wäre armer Anrufer, der gegen die Beschränkung verstoßen hat.

Wie drücken Sie die expliziten Einschränkungen für den Typ Arg aus? Sie hängen von der spezifischen Instanziierung von F ab. Diese Art von Abhängigkeit scheint in vielen der neueren Vorschläge für Einschränkungen zu fehlen.

Lassen Sie F und lassen Sie den Typ von f func (Arg) Result sein. Ja, es ignoriert variadische Funktionen, aber der Rest von Go tut es auch. Ein Vorschlag, Varargs funcs kompatiblen Signaturen zuweisbar zu machen, könnte separat gemacht werden.

In Fällen, in denen wir wirklich Typgrenzen höherer Ordnung benötigen, kann es sinnvoll sein, sie in Generics v1 aufzunehmen oder nicht. Explizite Einschränkungen zwingen uns, explizit zu entscheiden, ob wir Typen höherer Ordnung unterstützen wollen und wie. Die bisherige mangelnde Rücksichtnahme ist meines Erachtens ein Symptom dafür, dass Go derzeit keine Möglichkeit hat, auf Eigenschaften eingebauter Typen zu verweisen. Es ist eine allgemeine offene Frage, wie ein generisches System generische Funktionen über alle numerischen Typen oder alle ganzzahligen Typen zulassen wird, und die meisten Vorschläge haben sich nicht sehr darauf konzentriert.

Bitte bewerten Sie meine Generika-Implementierung in Ihrem nächsten Projekt
http://go-li.github.io/

Wir können Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() sagen. Diese Fehlermeldung […] liefert jemandem, der zu debuggen versucht, nicht, warum IndirectlyConstrained diese Einschränkung hat, was ein großes Usability-Problem ist, wenn es sich um eine große Funktion handelt.

Ich möchte auf eine große Annahme hinweisen, die Sie hier machen: dass die Fehlermeldung von go build das _einzige_ Werkzeug ist, das dem Programmierer zur Verfügung steht, um das Problem zu diagnostizieren.

Um eine Analogie zu verwenden: Wenn Sie zur Laufzeit auf ein error stoßen, haben Sie mehrere Möglichkeiten zum Debuggen. Der Fehler selbst enthält nur eine einfache Meldung, die zur Beschreibung des Fehlers geeignet sein kann oder nicht. Aber das ist nicht die einzige Information, die Ihnen zur Verfügung steht: Sie haben zum Beispiel auch alle Protokollanweisungen, die das Programm ausgegeben hat, und wenn es sich um einen wirklich knallharten Fehler handelt, können Sie ihn in einen interaktiven Debugger laden.

Das heißt, das Debuggen zur Laufzeit ist ein interaktiver Prozess. Warum also sollten wir nicht-interaktives Debugging für Kompilierzeitfehler annehmen⸮ Als eine Alternative könnten wir dem guru -Tool Type Constraints beibringen. Dann würde die Ausgabe des Compilers etwa so aussehen:

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`.)

Das gibt dem Benutzer des generischen Pakets die Informationen, die er braucht, um die Seite mit dem sofortigen Aufruf zu debuggen, aber _auch_ gibt dem Paketbetreuer (und, was noch wichtiger ist, seiner Bearbeitungsumgebung!) einen Breadcrumb, um weitere Nachforschungen anzustellen.

Wir könnten Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N hinzufügen, aber jetzt geben wir Details zur Implementierung von IndirectlyConstrained preis.

Ja, das meine ich damit, dass Informationen sowieso durchsickern. Sie können guru describe bereits verwenden, um einen Blick in eine Implementierung zu werfen. Sie können mit einem Debugger einen Blick in ein laufendes Programm werfen und nicht nur den Stack nachschlagen, sondern auch in beliebig niedrige Funktionen heruntersteigen.

Ich stimme absolut zu, dass wir wahrscheinlich irrelevante Informationen _standardmäßig_ verbergen sollten, aber das bedeutet nicht, dass wir sie absolut verbergen müssen.

Wenn eine implizit eingeschränkte Funktion für i := range t für einige t des generischen Typs T funktioniert, funktioniert die Syntax, wenn T irgendein Array, Slice oder Kanal ist , oder Karte. Aber die Semantik ist ganz anders, besonders wenn T ein Kanaltyp ist.

Ich denke, das ist das überzeugendere Argument für Typbeschränkungen, aber das erfordert nicht, dass explizite Beschränkungen auch nur annähernd so ausführlich sind wie das, was einige Leute vorschlagen. Um Aufrufseiten eindeutig zu machen, scheint es ausreichend zu sein, die Typparameter durch etwas näher an reflect.Kind . Wir müssen keine Operationen beschreiben, die bereits aus dem Code ersichtlich sind; Stattdessen müssen wir nur Dinge wie „ T ist ein Slice-Typ“ sagen. Das führt zu einer viel einfacheren Reihe von Einschränkungen:

• ein Typ, der Indexoperationen unterliegt, muss als linear oder assoziativ gekennzeichnet werden,
• ein Typ, der range -Operationen unterliegt, muss als nil-empty oder nil-blocking gekennzeichnet werden,
• ein Typ mit Literalen muss mit Feldern oder Indizes gekennzeichnet werden, und
• (vielleicht) muss ein Typ mit numerischen Operationen als Fest- oder Fließkomma gekennzeichnet werden.

Das führt zu einer viel engeren Beschränkungssprache, vielleicht so etwas wie:

TypeConstraint = "sliceable" | "map" | "chan" | "struct" | "integer" | "float" | "type"

mit Beispielen wie:

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)]
}

Ich habe das Gefühl, dass wir einen großen Schritt in Richtung benutzerdefinierter generischer Typen gemacht haben, indem wir Typ-Alias ​​eingeführt haben.
Typ-Alias ​​ermöglicht Super-Typen (Typen von Typen).
Wir können Typen bei using wie Werte behandeln.

Um die Erklärungen zu vereinfachen, können wir ein neues Codeelement hinzufügen, genre .
Die Beziehung zwischen Gattungen und Typen ist wie die Beziehung zwischen Typen und Werten.
Mit anderen Worten, ein Genre bedeutet eine Art von Typen.

Jede Art von Typ, mit Ausnahme von struct- und interface- und function-Arten, entspricht einem vorher deklarierten Genre.

• Bool
• Schnur
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint, Uintptr
• Float32, Float64
• Komplex64, Komplex128
• Array, Slice, Map, Kanal, Pointer, UnsafePointer

Es gibt einige andere vordeklarierte Genres, wie z. B. Comaprable, Numeric, Integer, Float, Complex, Container usw. Wir können Type oder * verwenden, um das Genre aller Typen zu bezeichnen.

Die Namen aller eingebauten Genres beginnen alle mit einem Großbuchstaben.

Jede Struktur und jeder Schnittstellen- und Funktionstyp entspricht einem Genre.

Wir können auch benutzerdefinierte Genres deklarieren:

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

Um die folgende Erklärung konsistent zu machen, wird ein Genre-Modifikator benötigt.
Der Genre-Modifizierer wird mit Const bezeichnet. Beispielsweise:

• Const Integer ist ein Genre (anders als Integer ) und seine Instanz muss ein konstanter Wert sein, dessen Typ eine ganze Zahl sein muss. Der konstante Wert kann jedoch als besonderer Typ angesehen werden.
• Const func(int) bool ist ein Genre (anders als func(int) bool ) und seine Instanz muss ein decarierter Funktionswert sein. Die Funktionsdeklaration kann jedoch als besonderer Typ betrachtet werden.

(Die Modifikatorlösung ist etwas knifflig, vielleicht gibt es andere bessere Designlösungen.)

Okay, machen wir weiter.
Wir brauchen ein anderes Konzept. Einen guten Namen dafür zu finden ist nicht einfach,
Nennen wir es einfach crate .
Im Allgemeinen ist die Beziehung zwischen Kisten und Genres wie die Beziehung zwischen Funktionen und Typen.
Eine Kiste kann Typen als Parameter und Rückgabetypen annehmen.

Eine Kistendeklaration (angenommen, der folgende Code ist im Paket lib deklariert):

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
}

Verwenden Sie die obige Kiste.

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)
}

Meine Ideen absorbieren viele der oben gezeigten Ideen anderer.
Sie sind jetzt sehr unreif.
Ich poste sie hier, nur weil ich finde, dass sie interessant sind,
und ich will es nicht mehr verbessern.
So viele Gehirnzellen wurden getötet, indem die Löcher in den Ideen repariert wurden.
Ich hoffe, dass diese Ideen andere Gophers inspirieren können.

Was Sie „Genre“ nennen, heißt eigentlich „Art“ und ist in der Welt bekannt
funktionale Programmiergemeinschaft. Was Sie eine Kiste nennen, ist eine eingeschränkte
eine Art ML-Funktor.

Am Mittwoch, 4. April 2018, 12:41 Uhr schrieb dotaheor [email protected] :

Ich habe das Gefühl, dass wir mit der Einführung einen großen Schritt in Richtung benutzerdefinierter Generika gemacht haben
Alias ​​eingeben.
Typ-Alias ​​ermöglicht Super-Typen (Typen von Typen).
Wir können Typen bei using wie Werte behandeln.

Um die Erklärungen einfacher zu machen, können wir ein neues Codeelement namens genre hinzufügen.
Die Beziehung zwischen Gattungen und Typen ist wie die Beziehung zwischen Typen
und Werte.
Mit anderen Worten, ein Genre bedeutet eine Art von Typen.

Jede Art von Typ, außer Struktur- und Schnittstellen- und Funktionsarten,
entspricht einem vorher festgelegten Genre.

• Bool
• Schnur
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint,
  Uintptr
  & Float32, Float64
• Komplex64, Komplex128
• Array, Slice, Map, Kanal, Pointer, UnsafePointer

Es gibt einige andere vordeklarierte Genres, wie Comparable, Numeric,
Integer, Float, Complex, Container usw. Wir können Typ oder * verwenden
das Genre aller Art.

Die Namen aller eingebauten Genres beginnen alle mit einem Großbuchstaben.

Jede Struktur und jeder Schnittstellen- und Funktionstyp entspricht einem Genre.

Wir können auch benutzerdefinierte Genres deklarieren:

Genre Addierbar = Numerisch | Schnur
Gattung Bestellbar = Integer | Schwimmer | Schnur
genre Validator = func(int) bool // Jeder Parameter und Ergebnistyp muss ein bestimmter Typ sein.
Genre HaveFieldsAndMethods = {
width int // Wir müssen einen bestimmten Typ verwenden, um die Felder zu definieren.
height int // Wir können kein Genre verwenden, um die Felder zu definieren.
Load(v []byte) error // Jeder Parameter und Ergebnistyp muss ein bestimmter Typ sein.
Etwas tun ()
}
genre GenreFromStruct = aStructType // ein Genre aus einem Strukturtyp deklarieren
genre GenreFromInterface = anInterfaceType // ein Genre aus einem Schnittstellentyp deklarieren
genre GenreFromStructInterface = aStructType | anInterfaceType

Um die folgende Erklärung konsistent zu machen, wird ein Genre-Modifikator benötigt.
Der Genre-Modifikator wird mit Const bezeichnet. Beispielsweise:

• Const Integer ist ein Genre und seine Instanz muss ein konstanter Wert sein
  welcher Typ muss eine Ganzzahl sein.
  Der konstante Wert kann jedoch als besonderer Typ angesehen werden.
• Const func(int) bool ist ein Genre und seine Instanz muss delcared sein
  Funktionswert.
  Die Funktionsdeklaration kann jedoch als besonderer Typ angesehen werden.

(Die Modifikatorlösung ist etwas knifflig, vielleicht gibt es andere bessere Designs
Lösungen.)

Okay, machen wir weiter.
Wir brauchen ein anderes Konzept. Einen guten Namen dafür zu finden ist nicht einfach,
Nennen wir es einfach Kiste.
Im Allgemeinen ist die Beziehung zwischen Kisten und Genres wie die Beziehung
zwischen Funktionen und Typen.
Eine Kiste kann Typen als Parameter und Rückgabetypen annehmen.

Eine Crate-Deklaration (angenommen, der folgende Code ist in lib
Paket):

Kiste Beispiel [T Float, S {Breite, Höhe T}, N Const Integer] [*, *, *] {
Geben Sie MyArray [N]T ein

func Add(a, b T) T {
gib a+b zurück
}

// Ein Kisten-Scope-Genre. Kann nur in der Kiste verwendet werden.

// M ist eine Art von Genre G
Typ M Struktur {
xT
y S
}

func (m *M) Bereich() T {
m.DoSothing()
geben Sie meine Breite * meine Höhe zurück
}

func (m *M) Perimeter() T {
return 2 * Add(meineBreite, meineHöhe)
}

export M, Hinzufügen, MyArray
}

Verwenden Sie die obige Kiste.

importiere "lib"

// Wir können AddFunc als normale Delcared-Funktion verwenden.
Typ Rect, AddFunc, Array = lib.Example(float32, struct{x, y float32})

func demo() {
var r Rect
a, p = r.Fläche(), r.Umfang()
_ = AddFunc(a, p)
}

Meine Ideen absorbieren viele der oben gezeigten Ideen anderer.
Sie sind jetzt sehr unreif.
Ich poste sie hier, nur weil ich finde, dass sie interessant sind,
und ich will es nicht mehr verbessern.
So viele Gehirnzellen wurden getötet, indem die Löcher in den Ideen repariert wurden.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment-378665695 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AGGWB78BrjN0BxRfroH-jRNy4mCXgSwCks5tlPfMgaJpZM4IG-xv
.

Ich habe das Gefühl, dass es einige Unterschiede zwischen Art und Genre gibt.

Übrigens, wenn eine Kiste nur einen Typ zurückgibt, können wir ihren Aufruf direkt als Typ verwenden.

package lib

// export a type
crate List [T *] * {
    type List struct {
        ...
    }

    export List
}

benutze es:

import "lib"

var l lib.List[int]

Es gäbe einige "Genre-Deduktion"-Regeln, genau wie die "Typ-Deduktion" im aktuellen System.

@dotaheor , @DemiMarie ist richtig. Ihr „Genre“-Konzept klingt genau wie das „Art“ aus der Typentheorie. (Ihr Vorschlag erfordert zufällig eine Subkinding-Regel, aber das ist nicht ungewöhnlich.)

Das Schlüsselwort genre in Ihrem Vorschlag definiert neue Arten als Superarten bestehender Arten. Das Schlüsselwort crate definiert Objekte mit „Kistensignaturen“, die eine Art sind, die keine Unterart von Type ist.

Als formales System scheint Ihr Vorschlag in etwa so zu sein:

Kiste ::= χ | ⋯
Geben Sie ::= τ | ein χ | int | bool | ⋯ | func(τ) | func(τ) τ | []τ | χ[τ₁, …]

CrateSig ::= [κ₁, …] ⇒ [κₙ, …]
Art ::= κ | exactly τ | kindOf κ | Map | Chan | ⋯ | Const κ | Type | CrateSig

Um eine typtheoretische Notation zu missbrauchen:

• Lesen Sie „⊢“ als „beinhaltet“.
• Lesen Sie „ k1 ⊑ k2 “ als „ k1 ist eine Unterart von k2 “.
• Lesen Sie „:“ als „ist von Art“.

Dann sehen die Regeln in etwa so aus:

⊢ τ : exactly τ
⊢ exactly τ ⊑ kindOf exactly τ
⊢ kindOf exactly τ ⊑ Type

τ : κ₁ ∧ κ₁ ⊑ κ₂ ⊢ τ : κ₂

τ₁ : Type ∧ τ₂ : Type ⊢ kindOf exactly map[τ₁]τ₂ ⊑ Map
⊢ Map ⊑ Type

κ₁ ⊑ κ₂ ⊢ Const κ₁ ⊑ Const κ₂

[…]
(Und so weiter, für alle eingebauten Arten)

Typdefinitionen verleihen Arten, und die zugrunde liegenden Arten fallen zu den Arten der eingebauten Typen zusammen:

type τ₁ τ₂ ∧ τ₂ : κ ⊢ τ₁ : kindOf κ

⊢ kindOf kindOf κ ⊑ kindOf κ
⊢ kindOf Map ⊑ Map
[…]

genre definiert neue Untertypbeziehungen:
genre κ = κ₁ | κ₂ ⊢ κ₁ ⊑ κ
genre κ = κ₁ | κ₂ ⊢ κ₂ ⊑ κ

(Sie können Numeric und dergleichen in Form von | definieren.)

genre κ = κ₁ & κ₂ ∧ ( κ₃ ⊑ κ₁ ) ∧ ( κ₃ ⊑ κ₂ ) ⊢ κ₃ ⊑ κ

Die Kistenerweiterungsregel ist ähnlich:
type τₙ, … = χ[τ₁, …] ∧ ( χ : [κ₁, …] ⇒ [κₙ, …] ) ∧ ( τ₁ : κ₁ ) ∧ ⋯ ⊢ τₙ : κₙ

Dies alles spricht natürlich nur über die Arten. Wenn Sie daraus ein Typsystem machen wollen, brauchen Sie auch Typregeln. 🙂

Was Sie also beschreiben, ist eine ziemlich gut verstandene Form der Parametrisierung. Das ist schön, da es gut verstanden wird, aber enttäuschend, da es nicht hilft, die einzigartigen Probleme zu lösen, die Go einführt.

Die wirklich interessanten und knorrigen Probleme, die Go einführt, betreffen hauptsächlich die dynamische Typprüfung. Wie sollten Typparameter mit Typzusicherungen und Reflektion interagieren?

(Sollte es beispielsweise möglich sein, Schnittstellen mit Methoden parametrischer Typen zu definieren? Wenn ja, was passiert, wenn Sie zur Laufzeit einen Wert dieser Schnittstelle mit einem neuartigen Parameter bestätigen?)

In einem ähnlichen Zusammenhang, gab es eine Diskussion darüber, wie man Code über eingebaute und benutzerdefinierte Typen generisch macht? Zum Beispiel Code erstellen, der Bigints und primitive Integer verarbeiten kann?

In einem ähnlichen Zusammenhang, gab es eine Diskussion darüber, wie man Code über eingebaute und benutzerdefinierte Typen generisch macht? Zum Beispiel Code erstellen, der Bigints und primitive Integer verarbeiten kann?

Typklassenbasierte Mechanismen wie in Genus und Familia können dies effizient tun. Einzelheiten finden Sie in unserem PLDI 2015-Papier.

@DemiMarie
Ich denke, "Genre" == "Eigenschaftssatz".

[bearbeiten]
Vielleicht ist traits ein besseres Schlüsselwort.
Wir können sehen, dass jede Art auch ein Merkmalssatz ist.

Die meisten Merkmale sind nur für einen einzigen Typ definiert.
Aber ein komplexeres Merkmal kann eine Beziehung zwischen zwei Typen definieren.

[Bearbeiten 2]
Angenommen, es gibt zwei Merkmalssätze A und B, können wir die folgenden Operationen durchführen:

A + B: union set
A - B: difference set
A & B: intersection set

Die Eigenschaftsmenge eines Argumenttyps muss eine Obermenge der entsprechenden Parametergattung (eine Eigenschaftsmenge) sein.
Die Merkmalsmenge eines Ergebnistyps muss eine Teilmenge des entsprechenden Ergebnistyps (eine Merkmalsmenge) sein.

(MEINER BESCHEIDENEN MEINUNG NACH)

Dennoch denke ich, dass das erneute Binden von Typ-Aliasen der richtige Weg ist, um Generika zu Go hinzuzufügen. Es braucht keine große Änderung in der Sprache. Auf diese Weise verallgemeinerte Pakete können weiterhin in Go 1.x verwendet werden. Und es besteht keine Notwendigkeit, Einschränkungen hinzuzufügen, da dies möglich ist, indem der Standardtyp für den Typalias auf etwas festgelegt wird, das diese Einschränkungen bereits erfüllt. Und der wichtigste Aspekt der erneuten Bindung von Typaliasen ist, dass die integrierten zusammengesetzten Typen (Slices, Maps und Channels) nicht geändert und generalisiert werden müssen.

@dc0d

Wie sollten Typaliase Generika ersetzen?

@sighoya Rebinding Type Aliases können Generika ersetzen (nicht nur Type Aliases). Nehmen wir an, ein Paket führt einige Typenaliase auf Paketebene ein wie:

package likedlist

type T = interface{}

type LinkedList struct {
    // ...
}

Wenn Type Alias ​​Rebinding (und Compiler-Einrichtungen) bereitgestellt werden, ist es möglich, dieses Paket zum Erstellen verknüpfter Listen für verschiedene konkrete Typen anstelle einer leeren Schnittstelle zu verwenden:

package main

import (
    "likedlist"
)

type intLL = likedlist.LinkedList(likedlist.T = int)
type stringLL = likedlist.LinkedList(likedlist.T = string)

func main() {}

Wenn wir den Alias ​​als solchen verwenden, ist der folgende Weg sauberer.

// 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 und wie genau würde das umgesetzt werden? Der Code ist nett, aber er sagt nichts darüber aus, wie er tatsächlich im Inneren funktioniert. Und wenn man sich die Geschichte der Generika-Vorschläge ansieht, ist es für Go sehr wichtig, nicht nur, wie es aussieht und sich anfühlt.

@dotaheor Das ist nicht kompatibel mit Go 1.x.

@creker Ich habe ein Tool (mit dem Namen goreuse ) implementiert, das diese Technik zum Generieren von Code verwendet und als Konzept für Type Alias ​​Rebinding geboren wurde.

Es ist hier zu finden. Es gibt ein 15-minütiges Video, das das Tool erklärt.

@dc0d , es funktioniert also ähnlich wie C++-Vorlagen, die spezialisierte Implementierungen generieren. Ich glaube nicht, dass es akzeptiert würde, da das Go-Team (und ehrlich gesagt ich und viele andere Leute hier) gegen etwas zu sein scheint, das C++-Vorlagen ähnlich ist. Es erhöht Binärdateien, verlangsamt die Kompilierung und wäre möglicherweise nicht in der Lage, sinnvolle Fehler zu erzeugen. Und darüber hinaus ist es nicht mit reinen Binärpaketen kompatibel, die Go unterstützt. Aus diesem Grund hat sich C++ dafür entschieden, Vorlagen in Header-Dateien zu schreiben.

@kreker

Es funktioniert also ähnlich wie C++-Vorlagen, die spezialisierte Implementierungen für jeden verwendeten Typ generieren.

Ich weiß es nicht (es ist ungefähr 16 Jahre her, seit ich C++ geschrieben habe). Aber nach deiner Erklärung scheint es so zu sein. Ich bin mir jedoch nicht sicher, ob oder wie sie gleich sind.

Ich glaube nicht, dass es akzeptiert würde, da das Go-Team (und ehrlich gesagt ich und viele andere Leute hier) gegen etwas zu sein scheint, das C++-Vorlagen ähnlich ist.

Sicherlich hat jeder hier gute Gründe für seine Präferenzen basierend auf seinen Prioritäten. Als erstes auf meiner Liste steht die Kompatibilität mit Go 1.x.

Es erhöht Binärdateien,

Es könnte.

verlangsamt die Kompilierung,

Ich bezweifle das sehr (wie es mit goreuse erlebt werden kann).

Und darüber hinaus ist es nicht mit reinen Binärpaketen kompatibel, die Go unterstützt.

Ich bin nicht sicher. Wird dies durch andere Möglichkeiten der Implementierung von Generika unterstützt?

möglicherweise nicht in der Lage, sinnvolle Fehler zu produzieren.

Dies könnte etwas mühsam sein. Dennoch passiert es zur Kompilierzeit und kann mit einigen Tools weitgehend kompensiert werden. Außerdem kann, wenn der Typalias, der als Typparameter für das Paket fungiert, eine Schnittstelle ist, einfach überprüft werden, ob er von dem konkret bereitgestellten Typ zuweisbar ist. Das Problem für primitive Typen wie int und string und Strukturen bleibt jedoch bestehen.

@dc0d

Ich denke ein bisschen darüber nach.
Außerdem ist es intern auf Schnittstellen festgelegt, in Ihrem Beispiel das 'T'

type T=interface{}

wird als veränderliche Typvariable behandelt, sollte aber ein Alias ​​für einen bestimmten Typ sein, dh eine konstante Referenz auf einen Typ.
Was Sie wollen, ist T Type, aber das würde die Einführung von Generika implizieren.

@sighoya Ich bin mir nicht sicher, ob ich verstehe, was du gesagt hast.

Es wird intern auf Schnittstellen aufgebaut

Nicht wahr. Wie in meinem ursprünglichen Kommentar beschrieben, ist es möglich, bestimmte Typen zu verwenden, die eine Einschränkung erfüllen. Beispielsweise kann der Aliastyp des Typparameters wie folgt deklariert werden:

type T = int

Und nur Typen mit dem Operator + (oder - oder * ; hängt davon ab, ob dieser Operator überhaupt im Hauptteil des Pakets verwendet wird) können als Typwert verwendet werden das sitzt in diesem Typparameter.

Es können also nicht nur Schnittstellen als Platzhalter für Typparameter verwendet werden.

dies würde jedoch die Einführung von Generika bedeuten.

Dies _ist_ eine Möglichkeit, Generika in der Go-Sprache selbst einzuführen/implementieren.

@dc0d

Um Polymorphismus bereitzustellen, verwenden Sie interface{}, da dies es ermöglicht, T später auf einen beliebigen Typ zu setzen.

Das Setzen von 'type T=Int' würde nicht viel bringen.

Wenn Sie sagen würden, dass „Typ T“ zuerst nicht deklariert/undefiniert ist, was später festgelegt werden kann, dann haben Sie so etwas wie Generika.

Das Problem dabei ist, dass 'T' das gesamte Modul/Paket enthält und nicht lokal für eine Funktion oder Struktur ist (okay, gut, vielleicht eine verschachtelte Typdeklaration in einer Struktur, auf die von außen zugegriffen werden kann).

Warum nicht stattdessen schreiben?:

fun<type T>(t T)

oder

fun[type T](t T)

Außerdem benötigen wir eine Art Inferenzmaschinerie, um die richtigen Typen abzuleiten, wenn eine generische Funktion oder Struktur zunächst ohne Typparameterspezialisierung aufgerufen wird.

@dc0d schrieb

Und nur Typen mit + Operator (oder - oder *; hängt davon ab, ob dieser Operator überhaupt im Hauptteil des Pakets verwendet wird) können als Typwert verwendet werden, der sich in diesem Typparameter befindet.

Können Sie das näher erläutern?

@sighoya

Um Polymorphismus bereitzustellen, verwenden Sie interface{}, da dies es ermöglicht, T später auf einen beliebigen Typ zu setzen.

Polymorphismus wird nicht durch kompatible Typen erreicht, wenn Typaliase neu gebunden werden. Die einzige tatsächliche Einschränkung ist der Hauptteil des generischen Pakets. Sie müssen mechanisch kompatibel sein.

Können Sie das näher erläutern?

Beispiel: Wenn ein Parametertyp-Alias ​​auf Paketebene wie folgt definiert ist:

package genericadd

type T = int

func Add(a, b T) T { return a + b }

Dann können praktisch alle numerischen Typen T zugewiesen werden, wie zum Beispiel:

package main

import (
    "genericadd"
)

var add = genericadd.Add(
    T = float64
)

func main() {
    var (
        a, b float64
    )

    println(add(a, b))
}

@dc0d

Ich bin mir jedoch nicht sicher, ob oder wie sie gleich sind.

Sie sind in dem Sinne gleich, dass sie, wie ich sehe, ziemlich identisch funktionieren. Für jede Klassenvorlagen-Instanziierung würde der Compiler eine eindeutige Implementierung generieren, wenn er zum ersten Mal die Verwendung der bestimmten Kombination aus Klassenvorlage und ihrer Parameterliste sieht. Dadurch wird die Binärgröße erhöht, da Sie jetzt mehrere Implementierungen derselben Klassenvorlage haben. Verlangsamt die Kompilierung, da der Compiler nun diese Implementierungen generieren und alle möglichen Überprüfungen durchführen müsste. Im Fall von C++ könnte die Verlängerung der Kompilierzeit enorm sein. Ihre Spielzeugbeispiele sind schnell, C++ aber auch.

Ich bin nicht sicher. Wird dies durch andere Möglichkeiten der Implementierung von Generika unterstützt?

Andere Sprachen haben damit kein Problem. Insbesondere C# ist mir am vertrautesten. Aber es verwendet Laufzeitcodegenerierung, die das Go-Team vollständig ausschließt. Java funktioniert auch, aber ihre Implementierung ist, gelinde gesagt, nicht die beste. Einige der ianlancetaylor-Vorschläge könnten nach meinem Verständnis nur binäre Pakete verarbeiten.

Das einzige, was ich nicht verstehe, ist, ob reine Binärpakete unterstützt werden müssen. Ich sehe nicht, dass sie in den Vorschlägen ausdrücklich erwähnt werden. Ich interessiere mich nicht wirklich für sie, aber trotzdem ist es eine Sprachfunktion.

Nur um mein Verständnis zu testen ... betrachten Sie dieses Repo von Copy/Paste-Algorithmen [ hier ]. Sofern Sie nicht "int" verwenden möchten, kann der Code nicht direkt verwendet werden. Es muss kopiert und eingefügt und geändert werden, damit es funktioniert. Und mit Modifikationen meine ich, dass jede Instanz von "int" in den Typ geändert werden muss, den Sie wirklich benötigen.

Der Typ-Alias-Ansatz würde die Änderungen einmal an beispielsweise T vornehmen und eine Zeile "type T int" einfügen. Dann müsste der Compiler T an etwas anderes binden, sagen wir float64.

Deswegen:
a) Ich würde argumentieren, dass es keine Verlangsamung des Compilers geben würde, es sei denn, Sie hätten diese Technik tatsächlich verwendet. Es ist also Ihre Wahl.
b) Angesichts des neuen vgo-Zeugs, wo mehrere Versionen desselben Codes verwendet werden können ... was bedeutet, dass es eine Methode geben muss, um die verwendeten Quellen außer Sichtweite zu verstauen, dann kann der Compiler sicherlich verfolgen, ob zwei Verwendungen der gleichen Neubindung verwendet werden und Duplikate vermieden werden. Ich denke also, dass Code Bloat das gleiche wäre wie bei aktuellen Copy/Paste-Techniken.

Es scheint mir, dass zwischen Typenaliasen und dem kommenden vgo die Grundlagen für diesen Ansatz für Generika fast vollständig sind ...

Es gibt einige "Unbekannte", die im Vorschlag [ hier ] aufgeführt sind. Es wäre also schön, es ein bisschen mehr zu konkretisieren.

@mandolyte Sie können eine weitere Indirektionsebene hinzufügen, indem Sie spezialisierte Typen in einen allgemeinen Container einschließen. Auf diese Weise kann Ihre Implementierung gleich bleiben. Der Compiler erledigt dann die ganze Magie. Ich denke, Ians Vorschlag für Typparameter funktioniert so.

Ich denke, der Benutzer muss zwischen Typlöschung und Monomorphisierung wählen können.
Letzteres ist der Grund, warum Rust kostenlose Abstraktionen anbietet. Gehen sollte auch.

Am Mo, 9. April 2018, 8:32 Uhr Antonenko Artem [email protected]
schrieb:

@mandolyte https://github.com/mandolyte können Sie eine weitere Ebene hinzufügen
Indirektion durch Einhüllen spezialisierter Typen in einen allgemeinen Container. Dass
wie Ihre Implementierung gleich bleiben kann. Der Compiler erledigt dann alles
die Magie. Ich denke, Ians Vorschlag für Typparameter funktioniert so.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment-379735199 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AGGWB1v9h5kWmuHCBuoewTTSX751OHgrks5tm1TsgaJpZM4IG-xv
.

Mir scheint, dass in dieser Diskussion über den Kompromiss zwischen Modularität und Leistung eine verständliche Verwirrung herrscht. Die C++-Technik der erneuten Typüberprüfung und Instanziierung von generischem Code bei jedem Typ, für den er verwendet wird, ist schlecht für die Modularität, schlecht für Binärdistributionen und aufgrund von aufgeblähtem Code schlecht für die Leistung. Das Gute an diesem Ansatz ist, dass der generierte Code automatisch auf die verwendeten Typen spezialisiert wird, was besonders hilfreich ist, wenn es sich bei den verwendeten Typen um primitive Typen wie int handelt. Java übersetzt generischen Code homogen, zahlt jedoch einen Preis in der Leistung, insbesondere wenn der Code den Typ T[] verwendet.

Glücklicherweise gibt es ein paar Möglichkeiten, dies ohne die Nicht-Modularität von C++ und ohne vollständige Generierung von Laufzeitcode anzugehen:

1. Generieren Sie spezialisierte Instanziierungen für primitive Typen. Dies könnte entweder automatisch oder durch eine Programmiereranweisung erfolgen. Ein gewisses Dispatching ist erforderlich, um auf die korrekte Instanziierung zuzugreifen, kann aber in das bereits benötigte Dispatching durch eine homogene Übersetzung gefaltet werden. Dies würde ähnlich wie C# funktionieren, erfordert jedoch keine vollständige Generierung von Laufzeitcode; Ein wenig zusätzliche Unterstützung könnte in der Laufzeit wünschenswert sein, um Dispatch-Tabellen einzurichten, wenn Code geladen wird.
2. Verwenden Sie eine einzelne generische Implementierung, in der ein Array von T tatsächlich als Array eines primitiven Typs dargestellt wird, wenn T als primitiver Typ instanziiert wird. Dieser Ansatz, den wir in PolyJ, Genus und Familia verwendet haben, verbessert die Leistung im Vergleich zum Java-Ansatz erheblich, obwohl er nicht ganz so schnell ist wie eine vollständig spezialisierte Implementierung.

@dc0d

Polymorphismus wird nicht durch kompatible Typen erreicht, wenn Typaliase neu gebunden werden. Die einzige tatsächliche Einschränkung ist der Hauptteil des generischen Pakets. Sie müssen mechanisch kompatibel sein.

Typaliase sind der falsche Weg, da es sich um eine konstante Referenz handeln sollte.
Es ist besser, direkt 'T Type' zu schreiben, und dann sehen Sie, dass Sie tatsächlich Generika verwenden.

Warum Sie eine globale Typvariable 'T' für das gesamte Paket/Modul verwenden möchten, lokale Typvariablen in <> oder [] sind modularer.

@kreker

Insbesondere C# ist mir am vertrautesten. Aber es verwendet Laufzeitcodegenerierung, die das Go-Team vollständig ausschließt.

Für Referenztypen, aber nicht für Werttypen.

@DemiMarie

Ich denke, der Benutzer muss zwischen Typlöschung und Monomorphisierung wählen können.
Letzteres ist der Grund, warum Rust kostenlose Abstraktionen anbietet. Gehen sollte auch.

"Type Erasure" ist mehrdeutig, ich nehme an, Sie meinen Type Parameter Erasure, das, was Java bietet, was auch nicht ganz stimmt.
Java hat eine Monomorphisierung, aber es monomorphisiert (halb) ständig bis zur oberen Grenze in der generischen Einschränkung, die meistens Object ist.
Um Methoden und Felder anderer Typen bereitzustellen, wird die Obergrenze intern in Ihren entsprechenden Typ umgewandelt, was ziemlich hässlich ist.
Wenn das Valhalla- Projekt akzeptiert wird, werden sich die Dinge für Werttypen ändern, aber leider nicht für Referenztypen.

Go muss nicht den Java-Weg gehen, weil:

"Binärkompatibilität für kompilierte Pakete zwischen Releases ist nicht garantiert"

während dies in Java nicht möglich ist.

Mir scheint, dass in dieser Diskussion über den Kompromiss zwischen Modularität und Leistung eine verständliche Verwirrung herrscht. Die C++-Technik der erneuten Typüberprüfung und Instanziierung von generischem Code bei jedem Typ, für den er verwendet wird, ist schlecht für die Modularität, schlecht für Binärdistributionen und aufgrund von aufgeblähtem Code schlecht für die Leistung.

Von welcher Leistung redest du hier?

Wenn Sie mit „aufgeblähtem Code“ und „Leistung“ „Binärgröße“ und „Anweisungs-Cache-Druck“ meinen, dann ist das Problem ziemlich einfach zu lösen: Solange Sie die Debug-Informationen für jede Spezialisierung nicht übermäßig aufbewahren, können Sie das kollabieren Funktionen mit denselben Körpern in dieselbe Funktion zur Verbindungszeit (das sogenannte „Borland-Modell“ ). Dadurch werden Spezialisierungen für primitive Typen und Typen ohne Aufrufe von nicht-trivialen Methoden behandelt.

Wenn Sie mit „Code-Bloat“ und „Performance“ „Linker-Eingabegröße“ und „Linking-Zeit“ meinen, dann ist das Problem auch ziemlich einfach, wenn Sie bestimmte (vernünftige) Annahmen über Ihr Build-System treffen können. Anstatt jede Spezialisierung in jeder Kompilierungseinheit auszugeben, können Sie stattdessen eine Liste der benötigten Spezialisierungen ausgeben und das Build-System jede eindeutige Spezialisierung genau einmal vor dem Verknüpfen instanziieren lassen (das „Cfront-Modell“). IIRC, dies ist eines der Probleme, die C++-Module zu lösen versuchen.

Wenn Sie also nicht eine dritte Art von „Code-Bloat“ und „Performance“ meinen, die ich übersehen habe, scheint es, als würden Sie von einem Problem mit der Implementierung sprechen, nicht mit der Spezifikation: _solange die Implementierung das Debug nicht überbewahrt Informationen,_ sind die Leistungsprobleme ziemlich einfach zu beheben.

Das größere Problem für Go besteht darin, dass es, wenn wir nicht aufpassen, möglich wird, Typzusicherungen oder Reflektion zu verwenden, um zur Laufzeit eine neuartige Instanz eines parametrisierten Typs zu erzeugen, was keine Menge an Implementierungsklugheit erfordert – abgesehen von einem teuren Ganzen ‐Programmanalyse – kann beheben.

Das ist in der Tat ein Versagen der Modularität, aber es hat nichts mit Code-Bloat zu tun: Stattdessen kommt es von der Tatsache, dass die Typen von Go-Funktionen (und -Methoden) keinen ausreichend vollständigen Satz von Einschränkungen für ihre Argumente erfassen.

@sighoya

Für Referenztypen, aber nicht für Werttypen.

Nach dem, was ich gelesen habe, führt C# JIT eine Spezialisierung zur Laufzeit für jeden Werttyp und einmal für alle Referenztypen durch. Es gibt keine Spezialisierung zur Kompilierzeit (IL-Zeit). Aus diesem Grund wird der C#-Ansatz vollständig ignoriert - das Go-Team möchte sich nicht auf die Generierung von Laufzeitcode verlassen, da dies die Plattformen einschränkt, auf denen Go ausgeführt werden kann. Insbesondere dürfen Sie unter iOS keine Codegenerierung zur Laufzeit durchführen. Es funktioniert und ich habe tatsächlich einiges davon gemacht, aber Apple erlaubt es nicht im AppStore.

Wie hast du es gemacht?

Am Mo, 9. April 2018, 15:41 Uhr Antonenko Artem [email protected]
schrieb:

@sighoya https://github.com/sighoya

Für Referenztypen, aber nicht für Werttypen.

Soweit ich gelesen habe, führt C# JIT eine Spezialisierung zur Laufzeit für jeden Wert durch
Typ und einmal für alle Referenztypen. Es gibt keine Kompilierzeit
Spezialisierung. Aus diesem Grund wird der C#-Ansatz vollständig ignoriert - Go team
möchte sich nicht auf die Generierung von Laufzeitcode verlassen, da dies die Plattformen Go einschränkt
weiterlaufen kann. Insbesondere dürfen Sie unter iOS keine Codegenerierung durchführen
zur Laufzeit. Es funktioniert und ich habe tatsächlich einiges davon gemacht, aber Apple erlaubt es nicht
es im AppStore.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment-379870005 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AGGWB-tslGeUSGXl2ZlEDLf0dCATUaYvks5tm7lvgaJpZM4IG-xv
.

@DemiMarie hat meinen alten Forschungscode gestartet, nur um sicherzugehen (dass die Forschung aus anderen Gründen eingestellt wurde). Wieder einmal führt mich der Debugger in die Irre. Ich weise eine Seite zu, schreibe einige Anweisungen dazu, mschütze sie mit PROT_EXEC und springe zu ihr. Unter Debugger funktioniert es. Ohne Debugger-App wird wie erwartet SIGKILL mit CODESIGN-Meldung im Absturzprotokoll angezeigt. Also auch ohne AppStore geht es nicht. Noch stärkeres Argument gegen die Generierung von Laufzeitcode, wenn iOS für Go wichtig ist.

Zunächst wäre es hilfreich, noch einmal über die 5 Programmierregeln von Rob Pike nachzudenken.

Zweitens (IMHO):

Bezüglich langsamer Kompilierung und Binärgröße, wie viele generische Typen werden in gängigen Anwendungstypen verwendet, die mit Go entwickelt werden (_n ist normalerweise klein_ aus Regel 3)? Sofern das Problem nicht eine hohe Kardinalität in konkreten Konzepten (hohe Anzahl von Typen) erfordert, kann dieser Overhead übersehen werden. Selbst dann würde ich argumentieren, dass etwas mit diesem Ansatz nicht stimmt. Bei der Implementierung eines E-Commerce-Systems definiert niemand einen separaten Typ für jede Art von Produkt und seine Variationen und möglicherweise die möglichen Anpassungen.

Ausführlichkeit ist eine gute Form der Einfachheit und Vertrautheit (z. B. in der Syntax), die die Dinge offensichtlicher und sauberer macht. Obwohl ich bezweifle, dass das Aufblähen des Codes mit Type Alias ​​Rebinding höher wäre, mag ich die vertraute Go-ish-Syntax und die damit einhergehende offensichtliche Ausführlichkeit. Eines der Ziele von Go ist es, leicht zu lesen zu sein (obwohl ich persönlich es relativ einfach und angenehm finde, darin zu schreiben).

Ich verstehe nicht, wie dies die Leistung beeinträchtigen kann, da zur Laufzeit nur konkrete begrenzte Typen verwendet werden, die zur Kompilierzeit generiert wurden. Es gibt keinen Laufzeit-Overhead.

Das einzige Problem mit Type Alias ​​Rebinding, das ich sehe, könnte die Binärverteilung sein.

@dc0d Leistungsschaden bedeutet normalerweise, dass der Anweisungscache aufgrund unterschiedlicher Implementierungen von Klassenvorlagen gefüllt wird. Wie genau das mit der realen Leistung zusammenhängt, ist eine offene Frage, mir sind keine Benchmarks bekannt, aber theoretisch ist es ein Problem.

Wie für binäre Größe. Es ist ein weiteres theoretisches Problem, das die Leute normalerweise ansprechen (wie ich es früher getan habe), aber wie der echte Code darunter leiden wird, ist wiederum eine offene Frage. Zum Beispiel könnte die Spezialisierung für alle Zeiger- und Schnittstellentypen gleich sein, denke ich. Eine Spezialisierung für alle Werttypen wäre jedoch einzigartig. Und dazu gehören auch Strukturen. Die Verwendung generischer Container zum Speichern ist üblich und würde zu einer erheblichen Aufblähung des Codes führen, da generische Containerimplementierungen nicht klein sind.

Das einzige Problem mit Type Alias ​​Rebinding, das ich sehe, könnte die Binärverteilung sein.

Hier bin ich mir noch nicht sicher. Muss der Generika-Vorschlag Nur-Binär-Pakete unterstützen oder wir könnten einfach erwähnen, dass Nur-Binär-Pakete keine Generika unterstützen. Es wäre viel einfacher, das ist sicher.

Wie bereits erwähnt, wenn man Debugging nicht unterstützen muss, kann man
können identische Template-Instanziierungen kombinieren.

Am Di, 10. April 2018, 5:46 Uhr Kaveh Shahbazian [email protected]
schrieb:

Zunächst wäre es hilfreich, über die 5 Programmierregeln von Rob Pike nachzudenken
https://users.ece.utexas.edu/%7Eadnan/pike.html noch einmal.

Zweitens (IMHO):

Über langsame Kompilierung und Binärgröße, wie viele generische Typen verwendet werden
allgemeine Arten von Anwendungen, die mit Go entwickelt werden ( n isnormalerweise klein aus Regel 3)? Es sei denn, das Problem erfordert ein hohes Maß an
Kardinalität in konkreten Konzepten (hohe Anzahl von Typen), die Overhead können
übersehen werden. Selbst dann würde ich behaupten, dass etwas daran nicht stimmt
sich nähern. Bei der Implementierung eines E-Commerce-Systems definiert niemand ein separates
Typ für jede Art von Produkt und seine Variationen und vielleicht das Mögliche
Anpassungen.

Ausführlichkeit ist eine gute Form der Einfachheit und Vertrautheit (zum Beispiel in
Syntax), was die Dinge offensichtlicher und sauberer macht. Wobei ich das bezweifle
Code-Bloat wäre mit Type Alias ​​Rebinding höher, ich mag das
vertraute Go-ish-Syntax und die damit einhergehende offensichtliche Ausführlichkeit. Einer von
Das Ziel von Go ist es, leicht lesbar zu sein (obwohl ich es persönlich finde
auch relativ einfach und angenehm zu schreiben).

Ich verstehe nicht, wie es die Leistung beeinträchtigen kann, weil nur zur Laufzeit
Es werden konkret begrenzte Typen verwendet, die bei generiert wurden
Kompilierzeit. Es gibt keinen Laufzeit-Overhead.

Das einzige Problem mit Type Alias ​​Rebinding, das ich sehe, könnte die Binärdatei sein
Verteilung.

—
Sie erhalten dies, weil Sie erwähnt wurden.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment-380040032 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AGGWB6aDfoHz2wbsmu8mCGEt652G_VE9ks5tnH9xgaJpZM4IG-xv
.

Die Instanziierungen müssen nicht einmal „identisch“ im Sinne von „die gleichen Argumente verwenden“ oder gar „Argumente mit demselben zugrunde liegenden Typ verwenden“ sein. Sie müssen nur nahe genug beieinander liegen, um zu demselben generierten Code zu führen. (Für Go impliziert das auch „die gleichen Zeigermasken“.)

@kreker

Nach dem, was ich gelesen habe, führt C# JIT eine Spezialisierung zur Laufzeit für jeden Werttyp und einmal für alle Referenztypen durch. Es gibt keine Spezialisierung zur Kompilierzeit (IL-Zeit).

Nun, das ist manchmal etwas kompliziert, weil ihr Bytecode gerade rechtzeitig interpretiert wird, bevor der Code ausgeführt wird. Die Codegenerierung erfolgt also vor der Ausführung des Programms, aber nach der Kompilierung. Sie haben also Recht im Sinne des vm, das während des Codes ausgeführt wird generiert wird.

Ich denke, dass das generische System von c# für Go in Ordnung wäre, wenn wir stattdessen Code zur Kompilierzeit generieren.
Laufzeitcodegenerierung im Sinne von c# ist mit go nicht möglich, da go keine vm ist.

@dc0d

Das einzige Problem mit Type Alias ​​Rebinding, das ich sehe, könnte die Binärverteilung sein.

Kannst du das etwas näher erläutern.

@sighoya Mein Fehler; Ich meinte nicht die Binärdistribution, sondern Binärpakete - von denen ich persönlich keine Ahnung habe, wie wichtig sie sind.

@creker Schöne Zusammenfassung! (MO) Sofern kein triftiger Grund gefunden wird, muss jede Form der Überladung der Go-Sprachkonstrukte vermieden werden. Ein Grund für Type Alias ​​Rebinding besteht darin, das Überladen integrierter zusammengesetzter Typen wie Slices oder Maps zu vermeiden.

Ausführlichkeit ist eine gute Form der Einfachheit und Vertrautheit (z. B. in der Syntax), die die Dinge offensichtlicher und sauberer macht. Obwohl ich bezweifle, dass das Aufblähen des Codes mit Type Alias ​​Rebinding höher wäre, mag ich die vertraute Go-ish-Syntax und die damit einhergehende offensichtliche Ausführlichkeit. Eines der Ziele von Go ist es, leicht zu lesen zu sein (obwohl ich persönlich es relativ einfach und angenehm finde, darin zu schreiben).

Ich bin mit dieser Vorstellung nicht einverstanden. Ihr Vorschlag wird Benutzer dazu zwingen, das Schwierigste zu tun, was Programmierern bekannt ist – Dinge zu benennen. Am Ende haben wir Code, der mit ungarischer Notation durchsetzt ist, was nicht nur schlecht aussieht, sondern auch unnötig ausführlich ist und Stottern verursacht. Darüber hinaus bringen auch andere Vorschläge eine Go-ish-Syntax ein und haben gleichzeitig diese Probleme nicht.

Es gibt drei Kategorien von Namen, die wir uns täglich ausdenken müssen:

• Für Domänenentitäten/Logik
• Programm-Workflow-Datentypen/Logik
• Dienste/Schnittstellendatentypen/Logik

Wie oft war es einem Programmierer jemals gelungen, es zu vermeiden, irgendetwas in seinem/ihrem Code zu benennen?

Schwer oder nicht, es muss täglich gemacht werden. Und die meisten Hürden kommen von der Inkompetenz bei der Strukturierung einer Codebasis - nicht von den Schwierigkeiten des Benennungsprozesses selbst. Dieses Zitat – zumindest in seiner jetzigen Form – hat der Welt der Programmierung bisher einen großen Bärendienst erwiesen. Es versucht lediglich, die Wichtigkeit der Namensgebung hervorzuheben. Weil wir in unserem Code über Namen kommunizieren.

Und Namen werden so viel mächtiger, wenn sie eine Codestrukturierungspraxis begleiten; sowohl in Bezug auf das Code-Layout (eine Datei, Verzeichnisstruktur, Pakete/Module) als auch in Bezug auf Praktiken (Entwurfsmuster, Dienstabstraktionen – wie REST, Ressourcenverwaltung – gleichzeitige Programmierung, Zugriff auf die Festplatte, Durchsatz/Latenz).

Was Syntax und Ausführlichkeit betrifft, bevorzuge ich Ausführlichkeit gegenüber cleverer Prägnanz (zumindest im Kontext von Go) - auch hier soll Go leicht zu lesen sein, nicht unbedingt leicht zu schreiben (was ich seltsamerweise auch gut finde). .

@jba siehe https://github.com/golang/go/issues/8303 und https://github.com/golang/go/issues/8082

Ich habe viele Erfahrungsberichte und Vorschläge gelesen, warum und wie man Generika in Go implementiert.

Stört es Sie, wenn ich versuche, sie tatsächlich in meinem Go-Interpreter gomacro zu implementieren?

Ich habe einige Erfahrung mit dem Thema, da ich in der Vergangenheit Generika zu zwei Sprachen hinzugefügt habe

1. eine jetzt aufgegebene Sprache , die ich damals erstellt habe, als ich naiv war :) Sie wurde in C-Quellcode transpiliert
2. Common Lisp mit meiner Bibliothek cl-parametric-types - es unterstützt auch teilweise und vollständige Spezialisierungen von generischen Typen und Funktionen

@ cosmos72 Es wäre ein schöner Erfahrungsbericht, einen Prototyp einer Technik zu sehen, die die Typsicherheit bewahrt.

Habe gerade angefangen daran zu arbeiten. Sie können den Fortschritt auf https://github.com/cosmos72/gomacro/tree/generics-v1 verfolgen

Im Moment beginne ich mit einer (leicht modifizierten) Mischung aus dem dritten und vierten Vorschlag von Ian, der unter https://github.com/golang/proposal/blob/master/design/15292-generics.md#Proposal aufgeführt ist

@cosmos72 Es gibt eine Zusammenfassung der Vorschläge unter dem Link unten. Gehört Ihre Mischung dazu?
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

Ich habe dieses Dokument gelesen, es fasst viele verschiedene Herangehensweisen an Generics durch verschiedene Programmiersprachen zusammen.

Im Moment gehe ich in Richtung der Technik der "Typspezialisierung", die von C++, Rust und anderen verwendet wird, möglicherweise mit ein wenig "parametrisierten Vorlagenbereichen", da die allgemeinste Go-Syntax für neue Typen type ( Foo ...; Bar ...) ist und ich erweitere es zu template[T1,T2...] type ( Foo ...; Bar ...) .
Außerdem halte ich die Tür für "eingeschränkte Spezialisierung" offen.

Ich möchte auch die "Spezialisierung polymorpher Funktionen" implementieren, dh dafür sorgen, dass die Spezialisierung automatisch von der Sprache an der Aufrufstelle abgeleitet wird, wenn sie nicht vom Programmierer angegeben wird, aber ich denke, die Implementierung kann etwas komplex sein. Wir werden sehen.

Die Mischung, auf die ich mich bezog, liegt zwischen https://github.com/golang/proposal/blob/master/design/15292/2013-10-gen.md und https://github.com/golang/proposal/blob/ master/design/15292/2013-12-type-params.md

Update: Um zu vermeiden, dass diese offizielle Go-Ausgabe über die ursprüngliche Ankündigung hinaus zugespammt wird, ist es wahrscheinlich besser, die gomacro-spezifische Diskussion in gomacro-Ausgabe Nr. 24 fortzusetzen: Generika hinzufügen

Update 2: erste Template-Funktionen kompiliert und erfolgreich ausgeführt. Siehe https://github.com/cosmos72/gomacro/tree/generics-v1

Nur fürs Protokoll, es ist möglich, meine Meinung (zu Generika und Type Alias ​​Rebinding) umzuformulieren:

Generics sollten als Compiler-Funktion (Codegenerierung, Vorlagen usw.) hinzugefügt werden, nicht als Sprachfunktion (Einmischung in das Typsystem von Go auf allen Ebenen).

@dc0d
Aber sind C++-Vorlagen nicht ein Compiler- und Sprachfeature?

@sighoya Das letzte Mal, als ich C++ professionell geschrieben habe, war ungefähr 2001. Also könnte ich mich irren. Aber vorausgesetzt, die Implikationen der Benennung sind korrekt - der "Vorlagen" -Teil - ja (oder eher nein); es könnte ein Compiler-Feature (und kein Sprachfeature) sein, begleitet von einigen Sprachkonstrukten, die höchstwahrscheinlich keine Sprachkonstrukte überladen, die am Typsystem beteiligt sind.

Ich unterstütze @dc0d. Wenn Sie es bedenken, wäre dieses Feature nichts anderes als ein integrierter Codegenerator.

Ja: Die Binärgröße kann und WIRD zunehmen, aber im Moment verwenden wir Codegeneratoren, die ziemlich gleich sind, aber als externes Feature. Wenn ich meine Vorlage erstellen muss als:

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

... Ich würde es ernsthaft begrüßen, wenn diese Funktion Teil des Compilers selbst wird, anstatt sie zu kopieren oder ein externes Tool zu verwenden.

Bitte beachten Sie:

• Ja, der Endcode würde dupliziert. Genauso, als ob wir einen Generator benutzen würden. Und die Binärdatei wäre größer.
• Ja, die Idee ist nicht originell, sondern von C++ entlehnt.
• Ja, Funktionen von MyTypenichts mit Typ T (direkt oder indirekt) involviert, würde ebenfalls wiederholt werden. Das könnte optimiert werden (z. B. werden Methoden, die auf etwas vom Typ T verweisen – außer dem Zeiger auf das Nachrichtenempfangsobjekt – für jedes T generiert; Methoden, die Aufrufe von Methoden enthalten, die dies tun würden für jedes T generiert werden, werden auch rekursiv für jedes T generiert - während Methoden, bei denen ihre einzige Referenz auf T *T ist, und andere Methoden, die nur diese sicheren Methoden aufrufen und dieselben Kriterien erfüllen, könnten nur einmal durchgeführt werden). Wie auch immer, IMO ist dieser Punkt groß und weniger auf den Punkt gebracht: Ich wäre ziemlich glücklich, auch wenn diese Optimierung nicht existiert.
• Typargumente sollten meiner Meinung nach explizit sein. Besonders wenn ein Objekt potenziell unendliche Schnittstellen erfüllt. Nochmal: ein Codegenerator.

Bisher in meinem Kommentar schlage ich vor, es so zu implementieren, wie es ist: als Compiler-unterstützter Codegenerator anstelle eines externen Tools.

Es wäre unglücklich, wenn Go der C++-Route folgen würde. Viele Leute betrachten den C++-Ansatz als ein Durcheinander, das Programmierer gegen die ganze Idee von Generika aufgebracht hat: Schwierigkeiten beim Debuggen, Mangel an Modularität, aufgeblähter Code. Alle „Code-Generator“-Lösungen sind eigentlich nur Makro-Ersetzungen – wenn Sie Code so schreiben wollen, warum brauchen wir dann überhaupt Compiler-Unterstützung?

@andrewcmyers Ich hatte diesen Vorschlag Type Alias ​​Rebinding, in dem wir nur normale Pakete schreiben und anstatt interface{} explizit zu verwenden, verwenden wir es einfach als type T = interface{} als generischen Parameter auf Paketebene. Und das ist alles.

• Wir debuggen es wie ein normales Paket – es ist tatsächlicher Code, nicht irgendeine Kreatur mit halber Lebensdauer.
• Es besteht keine Notwendigkeit, sich auf allen Ebenen in das Go-Typ-System einzumischen - denken Sie nur an die Zuweisbarkeit.
• Es ist explizit. Kein verstecktes Mojo. Natürlich kann es ein Nachteil sein, dass generische Aufrufe nicht nahtlos verkettet werden können. Ich sehe es als Draw-Forward! Änderungstyp in zwei aufeinanderfolgenden Aufrufen, in einer Aussage ist nicht Goish (IMO).
• Und das Beste ist, dass es abwärtskompatibel mit der Go 1.x (x >= 8) Serie ist.

Obwohl die Idee nicht neu ist, ist die Art und Weise, wie Go sie umsetzt, pragmatisch und klar.

Weiterer Bonus: In Go gibt es keine Operatorüberladung. Aber durch die Definition des Standardwerts des Typalias als (zum Beispiel) type T = int sind nicht die einzigen gültigen Typen, die zum Anpassen dieses generischen Pakets verwendet werden können, numerische Typen, die eine interne Implementierung für + haben

Auch der Alias-Typ-Parameter kann gezwungen werden, mehr als eine Schnittstelle zu erfüllen, indem einfach einige Validator-Typen und -Anweisungen hinzugefügt werden.

Nun, das wäre super hässlich, wenn Sie eine explizite Notation für einen generischen Typ verwenden würden, der einen Parameter hat, der Error - und Stringer -Schnittstellen implementiert, und auch ein numerischer Typ ist, der den + -Operator unterstützt !

Im Moment verwenden wir Codegeneratoren, die ziemlich gleich sind, aber als externes Feature.

Der Unterschied besteht darin, dass die allgemein akzeptierte Art der Codegenerierung (über go generate ) zur Commit-/Entwicklungszeit und nicht zur Kompilierzeit erfolgt. Wenn Sie dies zur Kompilierzeit tun, müssen Sie die Ausführung beliebigen Codes im Compiler zulassen, Bibliotheken können die Kompilierungszeiten um Größenordnungen sprengen und/oder Sie haben separate Build-Abhängigkeiten (dh Code kann nicht mehr nur mit Go Werkzeug). Ich mag Go dafür, dass es den Aufruf der Metaprogrammierung an den Upstream-Entwickler weiterleitet.

Das heißt, wie alle Ansätze zur Lösung dieser Probleme hat auch dieser Ansatz Nachteile und bringt Kompromisse mit sich. Persönlich würde ich argumentieren, dass tatsächliche Generika mit Unterstützung im Typsystem nicht nur besser sind (dh einen leistungsfähigeren Funktionssatz haben), sondern auch den Vorteil einer vorhersagbaren und sicheren Kompilierung behalten können.

Ich werde alles oben Gesagte lesen, das verspreche ich, und doch werde ich auch ein bisschen hinzufügen - GoLang SDK für Apache Beam scheint ein ziemlich leuchtendes Beispiel/Schaufenster für Probleme zu sein, die Bibliotheksdesigner ertragen müssen, um irgendetwas _richtig_ auf hohem Niveau zu erreichen.

Es gibt mindestens zwei experimentelle Implementierungen für Go-Generika. Anfang dieser Woche verbrachte ich einige Zeit mit (1). Ich war erfreut festzustellen, dass die Auswirkungen auf die Lesbarkeit des Codes minimal waren. Und ich fand, dass die Verwendung anonymer Funktionen zur Bereitstellung von Gleichheitstests gut funktionierte; Daher bin ich überzeugt, dass das Überladen von Operatoren nicht erforderlich ist. Das einzige Problem, das ich gefunden habe, war die Fehlerbehandlung. Die gebräuchliche Redewendung „return nil,err“ funktioniert nicht, wenn der Typ beispielsweise eine Ganzzahl oder ein String ist. Es gibt eine Reihe von Möglichkeiten, dies zu umgehen, die alle mit Komplexitätskosten verbunden sind. Ich mag etwas seltsam sein, aber ich mag die Fehlerbehandlung von Go. Dies führt mich zu der Beobachtung, dass eine Go-Generika-Lösung ein universelles Schlüsselwort für den Nullwert eines Typs haben sollte. Der Compiler würde es einfach durch Null für numerische Typen, eine leere Zeichenfolge für Zeichenfolgentypen und nil für Strukturen ersetzen.

Obwohl diese Implementierung keinen Ansatz auf Paketebene erzwang, wäre es sicherlich natürlich, dies zu tun. Und natürlich ging diese Implementierung nicht auf alle technischen Details darüber ein, wohin der vom Compiler instanziierte Code gehen sollte (falls irgendwo), wie Code-Debugger funktionieren würden usw.

Es war ganz nett, denselben Algorithmuscode für ganze Zahlen und so etwas wie einen Punkt zu verwenden:

type Point struct {
    x,y int
}

Siehe (2) für meine Tests und Beobachtungen.

(1) https://github.com/albrow/fo; die andere ist die oben erwähnte https://github.com/cosmos72/gomacro#generics
(2) https://github.com/mandolyte/fo-experiments

@mandolyte Sie können *new(T) verwenden, um den Nullwert eines beliebigen Typs zu erhalten.

Ein Sprachkonstrukt wie default(T) oder zero(T) (das erste ist das one
in C# IIRC) wäre klar, aber OTOH länger als *new(T) (obwohl mehr
leistungsfähig).

2018-07-06 9:15 GMT-05:00 Tom Thorogood [email protected] :

@mandolyte https://github.com/mandolyte Sie können *new(T) verwenden, um die
Nullwert jeglicher Art.

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment-403046735 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AlhWhQ5cQwnc3x_XUldyJXCHYzmr6aN3ks5uD3ETgaJpZM4IG-xv
.

--
Dies ist ein Test für E-Mail-Signaturen, die in TripleMint verwendet werden sollen

19642 dient zur Diskussion eines generischen Nullwerts

@tmthrgd Irgendwie habe ich diesen kleinen Leckerbissen verpasst. Danke!

Auftakt

Bei Generics dreht sich alles um die Spezialisierung anpassbarer Konstrukte. Drei Kategorien von Spezialisierungen sind:

• Spezialisierende Typen, Type<T> - ein _array_;
• Spezialisierung von Berechnungen, F<T>(T) oder F<T>(Type<T>) - ein _sortierbares Array_;
• Spezialisierte Notation, _LINQ_ zum Beispiel - select oder for Anweisungen in Go;

Natürlich gibt es Programmiersprachen, die noch generischere Konstrukte darstellen. Herkömmliche Programmiersprachen wie _C++_, _C#_ oder _Java_ bieten jedoch mehr oder weniger auf diese Liste beschränkte Sprachkonstrukte.

die Gedanken

Die erste Kategorie generischer Typen/Konstrukte sollte typunabhängig sein.

Die zweite Kategorie generischer Typen/Konstrukte muss auf eine _Eigenschaft_ des Typparameters _wirken_. Zum Beispiel muss ein _sortierbares Array_ in der Lage sein, die _vergleichbare Eigenschaft_ seiner Elemente zu _vergleichen_. Angenommen, T.(P) ist eine Eigenschaft von T und A(T.(P)) ist eine Berechnung/Aktion, die auf diese Eigenschaft einwirkt, kann (A, .(P)) entweder auf jedes einzelne Element angewendet werden oder als spezialisierte Berechnung deklariert werden, die an die ursprüngliche anpassbare Berechnung übergeben wird. Ein Beispiel für den letzteren Fall in Go ist die Schnittstelle sort.Interface , die auch die separate Funktion sort.Reverse als Gegenstück hat.

Die dritte Kategorie generischer Typen/Konstrukte sind _typ-spezialisierte_ Sprachnotationen - scheint _allgemein_ kein Go-Ding zu sein.

Fragen

Fortsetzung folgt ...

Jedes Feedback, das aussagekräftiger als ein Emoji ist, ist sehr willkommen!

@dc0d Ich würde empfehlen, Sepanovs "Elements of Programming" zu studieren, bevor Sie versuchen, Generics zu definieren. Das TL;DR ist, dass wir zunächst konkreten Code schreiben, sagen wir einen Algorithmus, der ein Array sortiert. Später fügen wir andere Sammlungstypen wie einen Btree usw. hinzu. Wir stellen fest, dass wir viele Kopien des Sortieralgorithmus schreiben, die im Wesentlichen gleich sind, also definieren wir ein Konzept, sagen wir „sortierbar“. Jetzt wollen wir die Sortieralgorithmen kategorisieren, vielleicht nach dem erforderlichen Zugriffsmuster, sagen wir nur vorwärts, Single Pass (ein Stream), nur Forward Multiple Pass (eine einfach verknüpfte Liste), bidirektional (eine doppelt verknüpfte Liste), wahlfreier Zugriff (ein Reihe). Wenn wir einen neuen Sammlungstyp hinzufügen, müssen wir nur angeben, in welche Kategorie von "Koordinaten" er fällt, um Zugriff auf alle relevanten Sortieralgorithmen zu erhalten. Diese Algorithmus-Kategorien sind „Go“-Schnittstellen sehr ähnlich. Ich würde versuchen, Schnittstellen in Go zu erweitern, um mehrere Typparameter und abstrakte/assoziierte Typen zu unterstützen. Ich glaube nicht, dass Funktionen eine Ad-hoc-Typparametrierung benötigen.

@dc0d Als Versuch, Generika in Bestandteile zu zerlegen, hatte ich 3, "spezialisierende Notation", zuvor nicht als eigenen separaten Teil betrachtet. Vielleicht könnte es als Definition von DSLs durch Verwendung von Typbeschränkungen charakterisiert werden.

Ich könnte argumentieren, dass Ihre 1 und 2 "Datenstrukturen" bzw. "Algorithmen" sind. Mit dieser Terminologie wird etwas klarer, warum es schwierig sein könnte, sie sauber zu trennen, da sie oft stark voneinander abhängig sind. Aber sort.Interface ist ein ziemlich gutes Beispiel dafür, wo Sie eine Grenze zwischen Speicherung und Verhalten ziehen können (mit ein wenig frischem Zucker, um es schöner zu machen), da es die Anforderungen Indizierbar und Vergleichbar in das Mindestverhalten codiert, das zur Implementierung des Sortieralgorithmus erforderlich ist mit "swap" und "less" (und len). Dies scheint jedoch an komplizierteren Datenstrukturen wie Bäumen oder Haufen zusammenzubrechen, die beide derzeit einige Verzerrungen erfordern, um sie in reines Verhalten als Go-Schnittstellen abzubilden.

Ich könnte mir eine relativ kleine generische Ergänzung zu Schnittstellen (oder auf andere Weise) vorstellen, mit der die meisten Lehrbuchdatenstrukturen und Algorithmen relativ sauber und ohne Verzerrungen implementiert werden könnten (wie es heute bei sort.Interface der Fall ist), die jedoch nicht leistungsfähig genug ist, um DSLs zu entwerfen. Ob wir uns auf eine so eingeschränkte Generika-Implementierung beschränken wollen , wenn wir uns überhaupt die Mühe machen, Generika hinzuzufügen, ist eine andere Frage.

@infogulch- Koordinatenstrukturen für Binärbäume sind "Gabelungskoordinaten", und es gibt Äquivalente für andere Bäume. Sie können jedoch auch die Bestellung eines Baums durch eine von drei Bestellungen projizieren: Vorbestellung, In-Bestellung und Nachbestellung. Wenn man sich für eines davon entschieden hat, kann der Baum als bidirektionale Koordinate adressiert werden, und die Familie von Sortieralgorithmen, die auf bidirektionalen Koordinaten definiert ist, wäre optimal effizient.

Der Punkt ist, dass Sie die Sortieralgorithmen nach ihren Zugriffsmustern kategorisieren. Für jedes Zugriffsmuster gibt es nur eine endliche Anzahl optimaler Sortieralgorithmen. Sie kümmern sich an dieser Stelle nicht um die Datenstrukturen. Von komplexeren Strukturen zu sprechen verfehlt den Punkt, wir wollen die Familie der Sortieralgorithmen kategorisieren, nicht die Datenstrukturen. Unabhängig davon, welche Daten Sie haben, müssen Sie einen der vorhandenen Algorithmen verwenden, um sie zu sortieren. Daher stellt sich die Frage, welche der verfügbaren Datenzugriffsmuster-Kategorisierungen von Sortieralgorithmen für die vorhandenen Datenstrukturen optimal ist.

(MEINER BESCHEIDENEN MEINUNG NACH)

@infogulch

Vielleicht könnte es als Definition von DSLs durch Verwendung von Typbeschränkungen charakterisiert werden

Sie haben Recht. Aber da sie Teil des Satzes von Sprachkonstrukten sind, wäre es meiner Meinung nach etwas ungenau, sie DSLs zu nennen.

1 und 2 ... sind oft stark abhängig

Wieder wahr. Aber es gibt viele Fälle, in denen ein Containertyp weitergegeben werden muss, während die tatsächliche Verwendung noch nicht entschieden ist - an diesem Punkt in einem Programm. Deshalb muss 1 alleine studiert werden.

sort.Interface ist ein ziemlich gutes Beispiel dafür, wo man eine Grenze zwischen _Speicher_ und _Verhalten_ ziehen kann.

Gut gesagt;

Dies scheint bei komplizierteren Datenstrukturen zusammenzubrechen

Das ist eine meiner Fragen: den Typparameter zu verallgemeinern und ihn in Form von Einschränkungen (wie List<T> where T:new, IDisposable ) zu beschreiben oder ein verallgemeinertes _Protokoll_ bereitzustellen, das auf alle Elemente (eines Satzes; eines bestimmten Typs) anwendbar ist?

@Keean

Es stellt sich die Frage, welche der verfügbaren Kategorisierungen von Datenzugriffsmustern von Sortieralgorithmen für die vorhandenen Datenstrukturen optimal ist

Wahr. Der Zugriff über den Index ist eine _Eigenschaft_ eines Slice (oder Arrays). Die erste Anforderung für einen sortierbaren Container (oder einen _baum_-fähigen Container, was auch immer der _Baum_-Algorithmus ist) ist die Bereitstellung eines Dienstprogramms für _Zugriff und Mutation (Swap)_. Die zweite Voraussetzung ist, dass die Artikel vergleichbar sein müssen. Das ist (für mich) der verwirrende Teil dessen, was Sie Algorithmen nennen: Anforderungen müssen auf beiden Seiten erfüllt werden (auf dem Container und auf dem Typparameter). Das ist der Punkt, an dem ich mir eine pragmatische Umsetzung von Generika in Go nicht vorstellen kann. Jede Seite des Problems lässt sich in Bezug auf Schnittstellen perfekt beschreiben. Aber wie kombiniert man diese beiden in einer effektiven Notation?

@dc0d -Algorithmen benötigen Schnittstellen, Datenstrukturen stellen sie bereit. Dies reicht für die volle Allgemeingültigkeit aus, vorausgesetzt, die Schnittstellen sind ausreichend leistungsfähig. Schnittstellen werden nach Typen parametrisiert, aber Sie benötigen Typvariablen.

Nehmen wir das Beispiel „sort“, „Ord“ ist eine Eigenschaft des Typs, der im Container gespeichert ist, nicht der Container selbst. Das Zugriffsmuster ist eine Eigenschaft des Containers. Einfache Zugriffsmuster sind "Iteratoren", aber dieser Name kommt von C++, Stepanov bevorzugte "Koordinaten", da er auf komplexere mehrdimensionale Container angewendet werden kann.

Beim Versuch, sort zu definieren, wollen wir so etwas:

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

Hinweis: Ich schlage diese Notation nicht vor, sondern versuche nur, andere verwandte Arbeiten einzubeziehen, die require-Klausel ist in der von Stepanov bevorzugten Syntax, der Funktionstyp stammt von Haskell, dessen Typklassen wahrscheinlich eine gute Implementierung dieser Konzepte darstellen.

@Keean
Vielleicht verstehe ich Sie falsch, aber ich glaube nicht, dass Sie Algorithmen einfach nur auf Schnittstellen beschränken können, zumindest nicht in der Art und Weise, wie Schnittstellen derzeit definiert werden.
Betrachten Sie zum Beispiel sort.Slice, wir sind daran interessiert, Slices zu sortieren, und ich sehe nicht, wie man eine Schnittstelle konstruieren würde, die alle Slices darstellen würde.

@urandom Sie abstrahieren die Algorithmen, nicht die Sammlungen. Sie fragen also, welche Datenzugriffsmuster in "Sortier"-Algorithmen existieren, und klassifizieren diese dann. Es spielt also keine Rolle, ob der Container ein "Slice" ist, wir versuchen nicht, alle Operationen zu definieren, die Sie möglicherweise auf einem Slice ausführen möchten, wir versuchen, die Anforderungen eines Algorithmus zu bestimmen und diese zu verwenden, um eine Schnittstelle zu definieren. Ein Slice ist nichts Besonderes, es ist nur ein Typ T, für den wir eine Reihe von Operationen definieren können.

Schnittstellen beziehen sich also auf Bibliotheken von Algorithmen, und Sie können Ihre eigenen Schnittstellen für Ihre eigenen Datenstrukturen definieren, um diese Algorithmen verwenden zu können. Die Bibliotheken könnten mit vordefinierten Schnittstellen für die eingebauten Typen geliefert werden.

@Keean
Ich dachte, das meinst du. Aber im Kontext von Go würde dies wahrscheinlich bedeuten, dass eine grundlegende Überarbeitung dessen erforderlich wäre, was Schnittstellen definieren können. Ich könnte mir vorstellen, dass verschiedene integrierte Operationen, wie Iterationen oder Operatoren, über Methoden verfügbar gemacht werden müssten, damit Dinge wie sort.Slice oder math.Max über Schnittstellen generisch gemacht werden können.

Sie müssten also Unterstützung für die folgende Schnittstelle (Pseudocode) haben:

type [T] OrderedIterator interface {
   Len() int
   ValueAt(i int) *T
}

...
package sort

func [T] Slice(s [T]OrderedIterator, func(i, j int) bool) {
   ...
}

und alle Slices hätten dann diese Methoden?

@urandom Ein Iterator ist keine Abstraktion einer Sammlung, sondern eine Abstraktion der Referenz/des Zeigers in eine Sammlung. Zum Beispiel könnte der Forward-Iterator eine einzelne Methode „successor“ (manchmal „next“) haben. Auf Daten am Speicherort eines Iterators zugreifen zu können, ist keine Eigenschaft des Iterators (andernfalls erhalten Sie am Ende Lese-/Schreib-/änderbare Varianten des Iterators). Es ist am besten, "Referenzen" separat als lesbare, beschreibbare und veränderliche Schnittstellen zu definieren:

type T ForwardIterator interface {
   type DistanceType D
   successor(x T) T
}

type T Readable interface {
   type ValueType U 
   source(x T) U
}

Hinweis: Der Typ 'T' ist nicht der Slice, sondern der Typ des Iterators auf dem Slice. Dies könnte nur ein einfacher Zeiger sein, wenn wir den C++-Stil übernehmen, einen Start- und End-Iterator an Funktionen wie sort zu übergeben.

Für einen Iterator mit wahlfreiem Zugriff würden wir am Ende so etwas wie:

type T RandomIterator interface {
   type DistanceType D
   setPosition(x DistanceType)
}

Ein Iterator/eine Koordinate ist also eine Abstraktion des Verweises auf eine Sammlung, nicht die Sammlung selbst. Der Name „Koordinate“ drückt dies recht gut aus, wenn man sich den Iterator als Koordinate und die Sammlung als Karte vorstellt.

Verkaufen wir nicht Go short, indem wir Funktionsschließungen und anonyme Funktionen nicht nutzen? Funktionen/Methoden als erstklassigen Typ in Go zu haben, kann hilfreich sein. Unter Verwendung der Syntax von albrow/fo könnte eine Blasensortierung beispielsweise so aussehen:

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
            }
        }
    }
}

Bitte übersehen Sie eventuelle Fehler ... völlig ungetestet!

@mandolyte Ich bin mir nicht sicher, ob dies an mich adressiert war? Ich sehe keinen wirklichen Unterschied zwischen dem, was ich vorgeschlagen habe, und Ihrem Beispiel, außer dass Sie Schnittstellen mit mehreren Parametern verwenden und ich Beispiele mit abstrakten/assoziierten Typen gegeben habe. Um es klar zu sagen, ich denke, Sie brauchen sowohl Multiparameter-Schnittstellen als auch abstrakte/assoziierte Typen für die volle Allgemeingültigkeit, die beide derzeit nicht von Go unterstützt werden.

Ich würde vorschlagen, dass Ihre Schnittstellen weniger allgemein sind als die von mir vorgeschlagenen, da sie die Sortierreihenfolge, das Zugriffsmuster und die Zugänglichkeit an dieselbe Schnittstelle binden, was natürlich zu einer Vermehrung von Schnittstellen führen wird, zum Beispiel zwei Ordnungen (weniger , größer), drei Zugriffsarten (read-only, write-only, mutable) und fünf Zugriffsmuster (forward-single-pass, forward-multi-pass, bidirectional, indexed, random) würden zu 36 statt nur 11 Schnittstellen führen wenn die Bedenken getrennt gehalten werden.

Sie könnten die von mir vorgeschlagenen Schnittstellen mit Multiparameter-Schnittstellen anstelle von abstrakten Typen wie diesen definieren:

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
}

Beachten Sie, dass die einzige, die zwei Typparameter benötigt, die Readable-Schnittstelle ist. Wir verlieren jedoch die Fähigkeit eines Iteratorobjekts, den Typ der iterierten Objekte zu 'enthalten', was ein großes Problem darstellt, da wir jetzt den 'Wert'-Typ im Typsystem verschieben müssen, und wir müssen es richtig machen . Dies führt zu einer unerwünschten Vermehrung von Typparametern und erhöht die Möglichkeit von Codierungsfehlern. Wir verlieren auch die Möglichkeit, den „DistanceType“ auf dem Iterator zu definieren, der der kleinste Zahlentyp ist, der zum Zählen der Elemente in der Sammlung erforderlich ist, was für die Zuordnung zu int8, int16, int32 usw. nützlich ist, um den Typ zu erhalten, den Sie benötigen Elemente ohne Überlauf zählen.

Dies ist eng mit dem Konzept der „funktionalen Abhängigkeit“ verbunden. Wenn ein Typ funktional von einem anderen Typ abhängig ist, sollte es sich um einen abstrakten/assoziierten Typ handeln. Nur wenn die beiden Typen unabhängig sind, sollten sie separate Typparameter sein.

Einige Probleme:

1. Die aktuelle f(x I)-Syntax kann für Schnittstellen mit mehreren Parametern nicht verwendet werden. Ich mag es nicht, dass diese Syntax Schnittstellen (die Einschränkungen für Typen sind) sowieso mit Typen verwechselt.
2. Es bräuchte eine Möglichkeit, parametrisierte Typen zu deklarieren.
3. Es müsste eine Möglichkeit geben, zugeordnete Typen für Schnittstellen mit einem bestimmten Satz von Typparametern zu deklarieren.

@keean Ich bin mir nicht sicher, ob ich verstehe, wie oder warum die Anzahl der Schnittstellen so hoch wird. Hier ist ein vollständiges Arbeitsbeispiel: https://play.folang.org/p/BZa6BdsfBgZ (slice-basiert, kein allgemeiner Container, daher keine Next()-Methode erforderlich).

Es verwendet nur eine Typstruktur, überhaupt keine Schnittstellen. Ich muss alle anonymen Funktionen und Schließungen bereitstellen (das ist wahrscheinlich der Kompromiss?). Das Beispiel verwendet den gleichen Blasensortierungsalgorithmus, um sowohl ein Segment von Ganzzahlen als auch ein Segment von „(x,y)“-Punkten zu sortieren, wobei die Entfernung vom Ursprung die Grundlage der Less()-Funktion ist.

Auf jeden Fall wollte ich zeigen, wie es helfen kann, Funktionen im Typsystem zu haben.

@mandolyte Ich glaube, ich habe deinen Vorschlag falsch verstanden. Ich sehe, wovon Sie sprechen, ist "folang", das Go bereits einige nette funktionale Programmierfunktionen hinzugefügt hat. Was Sie implementiert haben, ist im Grunde genommen, eine Typklasse mit mehreren Parametern von Hand auszufüllen. Sie übergeben ein sogenanntes Funktionswörterbuch an die Sortierfunktion. Dies tut explizit das, was eine Schnittstelle implizit tun würde. Diese Art von Funktionen werden wahrscheinlich vor Schnittstellen mit mehreren Parametern und zugehörigen Typen benötigt, aber irgendwann stoßen Sie auf Probleme, wenn Sie all diese Wörterbücher herumgeben. Ich denke, Schnittstellen sorgen für saubereren, besser lesbaren Code.

Das Sortieren eines Slice ist ein gelöstes Problem. Hier ist der Code für ein Slice quicksort.go , das mit der go-li-Sprache (golang-verbessert) implementiert wurde .

func main(){
    var data = []int{5,3,1,8,9}

    Sort(data, func(a *int, b *int) int {
        return *a - *b
    })

    fmt.Println(data)
}

Auf dem Spielplatz kann man damit experimentieren

Das vollständige Beispiel können Sie in den Spielplatz einfügen , da das Importieren des Quicksort-Pakets auf dem Spielplatz nicht funktioniert.

@go-li Ich bin sicher, Sie können ein Stück sortieren, es wäre ein bisschen schlecht, wenn Sie es nicht könnten. Der Punkt ist im Allgemeinen, dass Sie in der Lage sein möchten, jeden linearen Container mit demselben Code zu sortieren, sodass Sie immer nur einmal einen Sortieralgorithmus schreiben müssen, egal welchen Container (Datenstruktur) Sie sortieren und egal was Inhalt ist.

Wenn Sie dies tun können, kann die Standardbibliothek universelle Sortierfunktionen bereitstellen, und niemand muss jemals wieder eine schreiben. Dies hat zwei Vorteile, weniger Fehler, da es schwieriger ist, einen korrekten Sortieralgorithmus zu schreiben, als Sie denken. Stepanov verwendet das Beispiel, dass die meisten Programmierer das Paar „min“ und „max“ nicht richtig definieren können. Welche Hoffnung müssen wir also haben? korrekt für komplexere Algorithmen. Der andere Vorteil besteht darin, dass, wenn es nur eine Definition für jeden Sortieralgorithmus gibt, alle Verbesserungen der Klarheit oder Leistung, die vorgenommen werden können, allen Programmen zugute kommen, die ihn verwenden. Die Leute können ihre Zeit damit verbringen, den gemeinsamen Algorithmus zu verbessern, anstatt für jeden anderen Datentyp einen eigenen schreiben zu müssen.

@Keean
Eine weitere Frage bezieht sich auf unsere vorherige Diskussion. Ich kann nicht herausfinden, wie man eine Zuordnungsfunktion definieren könnte, die Elemente von einem iterierbaren ändert und einen neuen konkreten iterierbaren Typ zurückgibt, dessen Elemente möglicherweise einen anderen Typ als den ursprünglichen haben.

Und ich kann mir vorstellen, dass ein Benutzer einer solchen Funktion einen konkreten Typ zurückgeben möchte, nicht eine andere Schnittstelle.

@urandom Angenommen, wir wollen es nicht an Ort und Stelle tun, was unsicher wäre, was Sie wollen, ist eine Kartenfunktion, die einen „Lese-Iterator“ eines Typs und einen „Schreib-Iterator“ eines anderen Typs hat. was etwa so definiert werden kann:

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)

Der Übersichtlichkeit halber ist "ValueType" ein assoziierter Typ der Schnittstellen "Readable" und "Writable", "Domain" und "Codomain" sind assoziierte Typen der Schnittstelle "UnaryFunction". Es hilft natürlich sehr, wenn der Compiler die Schnittstellen für Datentypen wie "UnaryFunction" automatisch ableiten kann. Während diese Art von Reflektion aussieht, ist sie es nicht, und alles geschieht zur Kompilierzeit mit statischen Typen.

@keean Wie kann man diese Lese- und Schreibbeschränkungen im Kontext der aktuellen Go-Schnittstellen modellieren?

Ich meine, wenn wir einen Typ A haben und in den Typ B konvertieren wollen, wäre die Signatur dieser UnaryFunction func (input A) B (richtig?), aber wie kann das sein nur mit Schnittstellen modelliert werden und wie dieses generische map (oder filter , reduce usw.) modelliert werden würde, um die Pipeline von Typen beizubehalten?

@geovanisouza92 Ich denke, "Typfamilien" würden gut funktionieren, da sie als orthogonaler Mechanismus im Typsystem implementiert und dann wie in Haskell in die Syntax für Schnittstellen integriert werden können.

Eine Typfamilie ist wie eine eingeschränkte Funktion für Typen (eine Zuordnung). Da Schnittstellenimplementierungen nach Typ ausgewählt werden, können wir für jede Implementierung eine Typzuordnung bereitstellen.

Wenn wir also definieren:

ValueType MyIntArrayIterator -> Int

Funktionen sind ein wenig kniffliger, aber eine Funktion hat einen Typ, zum Beispiel:

fn(x : Int) Float

Wir würden diesen Typ schreiben:

Int -> Float

Es ist wichtig zu erkennen, dass -> nur ein Infix-Typkonstruktor ist, so wie '[]' für ein Array ein Typkonstruktor ist, wir könnten dies genauso gut schreiben;

Fn Int Float
Or
Fn<Int, Float>

Abhängig von unserer Präferenz für die Typsyntax. Jetzt können wir klar sehen, wie wir definieren können:

Domain  Fn<Int, Float> -> Int
Codomain Fn<Int, Float> -> Float

Während wir alle diese Definitionen von Hand bereitstellen könnten, können sie vom Compiler leicht abgeleitet werden.

Angesichts dieser Typfamilien können wir sehen, dass die oben angegebene Definition von map nur die Typen IO und U erfordert, um das Generikum zu instanziieren, da alle anderen Typen funktional von diesen abhängig sind. Wir können sehen, dass diese Typen direkt von den Argumenten bereitgestellt werden.

Danke, @keean.

Dies würde für eingebaute/vordefinierte Funktionen gut funktionieren. Wollen Sie damit sagen, dass dasselbe Konzept für benutzerdefinierte Funktionen oder Userland-Bibliotheken angewendet wird?

Diese "Typfamilien" werden im Falle eines Fehlerkontexts zur Laufzeit mitgeführt?

Wie wäre es mit leeren Schnittstellen, Typschaltern und Reflektion?

EDIT: Ich bin nur neugierig und beschwere mich nicht.

@giovanisouza92 Nun , niemand hat Go verpflichtet, Generika zu haben, also erwarte ich Skepsis. Mein Ansatz ist, dass, wenn Sie Generika herstellen, Sie sie richtig machen sollten.

In meinem Beispiel ist 'map' benutzerdefiniert. Daran ist nichts Besonderes, und innerhalb der Funktion verwenden Sie einfach die Methoden der Schnittstellen, die Sie für diese Typen benötigt haben, genau wie Sie es jetzt in Go tun. Der einzige Unterschied besteht darin, dass ein Typ erforderlich sein kann, um mehrere Schnittstellen zu erfüllen, Schnittstellen können mehrere Typparameter haben (obwohl das Kartenbeispiel dies nicht verwendet) und es auch zugeordnete Typen gibt (und Einschränkungen für Typen wie die Typgleichheit '==' aber das ist wie eine Prolog-Gleichheit und vereinheitlicht die Typen). Aus diesem Grund gibt es die unterschiedliche Syntax zur Angabe der Schnittstellen, die von einer Funktion benötigt werden. Beachten Sie, dass es einen weiteren wichtigen Unterschied gibt:

f(x I, y I) requires ForwardIterator<I>

Vs

f(x ForwardIterator, y ForwardIterator)

Beachten Sie, dass es im letzteren einen Unterschied gibt, dass 'x' und 'y' unterschiedliche Typen sein können, die die ForwardIterator-Schnittstelle erfüllen, während in der früheren Syntax 'x' und 'y' beide vom gleichen Typ sein müssen (der den Forward-Iterator erfüllt). Dies ist wichtig, damit Funktionen nicht unterbeschränkt werden und konkrete Typen viel weiter während der Kompilierung weitergegeben werden können.

Ich glaube nicht, dass sich bezüglich Type Switches und Reflection etwas ändert, da wir lediglich das Interface-Konzept erweitern. Da go über Laufzeittypinformationen verfügt, geraten Sie nicht in das gleiche Problem wie Haskell und benötigen existentielle Typen.

Wenn wir an Go, Laufzeitpolymorphismus und Typfamilien denken, möchten wir wahrscheinlich die Typfamilie selbst auf eine Schnittstelle beschränken, um zu vermeiden, dass jeder zugeordnete Typ zur Laufzeit als leere Schnittstelle behandelt werden muss, was langsam wäre.

Angesichts dieser Gedanken würde ich meinen obigen Vorschlag so ändern, dass Sie beim Deklarieren einer Schnittstelle eine Schnittstelle/einen Typ für jeden zugeordneten Typ deklarieren, dass alle Implementierungen dieser Schnittstelle einen zugeordneten Typ bereitstellen müssten, der diese Schnittstelle erfüllt. Auf diese Weise können wir wissen, dass es sicher ist, alle Methoden von dieser Schnittstelle auf den zugehörigen Typen zur Laufzeit aufzurufen, ohne von einer leeren Schnittstelle aus den Typ wechseln zu müssen.

@Keean
Um die Debatte voranzutreiben, lassen Sie mich ein Missverständnis klarstellen, das meines Erachtens dem nicht erfundenen Syndrom ähnelt.

Bidirektionaler Iterator (in T-Syntax func (*T) *[2]*T ) hat den Typ func (*) *[2]* in go-li-Syntax. In Worten, es nimmt einen Zeiger auf einen Typ und gibt einen Zeiger auf zwei Zeiger auf das nächste und vorherige Element desselben Typs zurück. Es ist der grundlegende konkrete Fundamentaltyp, der von einer doppelt verknüpften Liste verwendet wird.

Jetzt können Sie schreiben, was Sie Map nennen, was ich die generische Funktion foreach nenne. Machen Sie keinen Fehler, dies funktioniert nicht nur über verknüpfte Listen, sondern über alles, was einen bidirektionalen Iterator offenlegt!

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
}

Der Foreach kann auf zwei Arten verwendet werden, Sie verwenden ihn mit einem Lambda in einer for-schleifenähnlichen Iteration über Listen- oder Sammlungselementen.

const forward = 1
const backwards = 0
Foreach(iterator, collection, forward, func(element *element_type){
    // do something with every element
})

Oder Sie können es verwenden, um jedem Sammlungselement eine Funktion funktional zuzuordnen.

Foreach(iterator, collection, backwards, function_to_be_mapped_on_elements)

Bidirektionaler Iterator kann natürlich auch über Schnittstellen in go 1 modelliert werden.
interface Iterator { Iter() [2]Iterator } Sie müssen es mithilfe von Schnittstellen modellieren, um den zugrunde liegenden Typ zu umschließen ("boxen"). Der Benutzer des Iterators bestätigt dann den bekannten Typ, sobald er ein bestimmtes Sammlungselement gefunden hat und besuchen möchte. Dies ist möglicherweise eine unsichere Kompilierzeit.

Was Sie als Nächstes beschreiben, sind die Unterschiede zwischen dem Legacy-Ansatz und dem auf Generika basierenden Ansatz.

func modern(x func  (*) *[2]*, y func  (*) *[2]*){}

Dieser Ansatz zur Kompilierzeit überprüft, ob die beiden Sammlungen denselben zugrunde liegenden Typ haben, mit anderen Worten, ob die Iteratoren tatsächlich dieselben konkreten Typen zurückgeben

func modern_T_syntax<T>(x func  (*T) *[2]*T, y func  (*T) *[2]*T){}

Dasselbe wie oben, aber unter Verwendung der bekannten Platzhaltersyntax für T bedeutet Typ

func legacy(x Iterator, y Iterator){}

In diesem Fall kann der Benutzer beispielsweise eine ganzzahlige verkettete Liste als x und eine verkettete Float-Liste als y übergeben. Dies könnte zu potenziellen Laufzeitfehlern, Panik oder anderen internen Dekohärenzen führen, aber alles hängt davon ab, was Legacy mit den beiden Iteratoren machen würde.

Jetzt der Denkfehler. Sie behaupten, dass das Ausführen von Iteratoren und das Ausführen generischer Sortierungen zum Sortieren dieser Iteratoren der richtige Weg wäre. Das wäre eine wirklich schlechte Sache, hier ist der Grund

Iterator und verkettete Liste sind zwei Seiten derselben Medaille. Beweis: Jede Sammlung, die Iterator verfügbar macht, bewirbt sich einfach als verknüpfte Liste. Nehmen wir an, Sie müssen das sortieren. Was tun?

Offensichtlich löschen Sie die verknüpfte Liste aus Ihrer Codebasis und ersetzen sie durch einen binären Baum. Oder wenn Sie schick sein wollen, verwenden Sie einen ausgewogenen Suchbaum wie avl, rot-schwarz, wie von Ian et all vorgeschlagen, ich weiß nicht, wie viele Jahre her. Dies wurde jedoch noch nicht generisch in Golang durchgeführt. Das wäre jetzt der richtige Weg.

Eine andere Lösung besteht darin, den Iterator schnell in einer O(N)-Zeitschleife zu durchlaufen, die Zeiger auf Elemente in einem Slice generischer Zeiger mit der Bezeichnung []*T zu sammeln und diese generischen Zeiger mit der schlechten Slice-Sortierung zu sortieren

Bitte geben Sie den Ideen anderer eine Chance

@go-li Wenn wir das Not-invented-here-Syndrom vermeiden wollen, sollten wir Alex Stepanov nach einer Definition fragen, da er so ziemlich die generische Programmierung erfunden hat. So würde ich es definieren, entnommen aus Stepanovs "Elements of Programming" Seite 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

Dies hängt von der Definition von ForwardIterator ab:

ForwardIterator<T> =
    Iterator<T>
/\ regular_unary_function(successor)

Im Wesentlichen haben wir also eine Schnittstelle, die eine successor -Funktion und eine predecessor -Funktion deklariert, zusammen mit einigen Axiomen, denen sie entsprechen müssen, um gültig zu sein.

In Bezug auf legacy ist es nicht so, dass Legacy schief gehen wird, in Go geht es offensichtlich derzeit nicht schief, aber dem Compiler fehlen Optimierungsmöglichkeiten und dem Typsystem fehlt die Möglichkeit, konkrete Typen weiter zu verbreiten. Es schränkt auch die Fähigkeit der Programmierer ein, ihre Absicht genau zu spezifizieren. Ein Beispiel wäre eine Identitätsfunktion, die genau den Typ zurückgeben soll, an den sie übergeben wird:

id(x T) T

Erwähnenswert ist vielleicht auch der Unterschied zwischen einem parametrischen Typ und einem universell quantifizierten Typ. Ein parametrischer Typ wäre id<T>(x T) T , während der universell quantifizierte Typ id(x T) T ist (normalerweise lassen wir in diesem Fall den äußersten universellen Quantor forall T ). Bei parametrischen Typen muss das Typsystem einen Typ für T haben, der auf der Aufrufseite für id bereitgestellt wird, wobei eine universelle Quantifizierung nicht erforderlich ist, solange T mit einem konkreten Typ vereinheitlicht wird, bevor die Kompilierung abgeschlossen ist. Eine andere Möglichkeit, dies zu verstehen, ist, dass die parametrische Funktion kein Typ, sondern eine Vorlage für einen Typ ist, und sie ist nur dann ein gültiger Typ, nachdem T durch einen konkreten Typ ersetzt wurde. Bei der universell quantifizierten Funktion hat id tatsächlich einen Typ forall T . T -> T , der vom Compiler genauso wie Int übergeben werden kann.

@go-li

Offensichtlich löschen Sie die verknüpfte Liste aus Ihrer Codebasis und ersetzen sie durch einen binären Baum. Oder wenn Sie schick sein wollen, verwenden Sie einen ausgewogenen Suchbaum wie avl, rot-schwarz, wie von Ian et all vorgeschlagen, ich weiß nicht, wie viele Jahre her. Dies wurde jedoch noch nicht generisch in Golang durchgeführt. Das wäre jetzt der richtige Weg.

Geordnete Datenstrukturen zu haben bedeutet nicht, dass Sie niemals Daten sortieren müssen.

Wenn wir das Not-invented-here-Syndrom vermeiden wollen, sollten wir Alex Stepanov nach einer Definition fragen, da er so ziemlich die generische Programmierung erfunden hat.

Ich würde jede Behauptung bestreiten, dass die generische Programmierung von C++ erfunden wurde. Lesen Sie die Liskov et al. CACM-Papier von 1977, wenn Sie ein frühes Modell generischer Programmierung sehen möchten, das tatsächlich funktioniert (typsicher, modular, kein aufgeblähter Code): https://dl.acm.org/citation.cfm?id=359789 (siehe Abschnitt 4 )

Ich denke, wir sollten diese Diskussion beenden und warten, bis das golang-Team (russ) mit einigen Blog-Beiträgen kommt, und dann eine Lösung implementieren 👍 (siehe vgo). Sie werden es einfach tun 🎉

https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html

Ich hoffe, diese Geschichte dient anderen als Warnung: Wenn Sie daran interessiert sind, wesentliche Beiträge zum Go-Projekt zu leisten, kann keine noch so große unabhängige Due Diligence ein Design kompensieren, das nicht vom Kernteam stammt.

Dieser Thread zeigt, dass das Kernteam kein Interesse daran hat, sich aktiv an der Lösungsfindung mit der Community zu beteiligen.

Aber am Ende, wenn sie wieder selbst eine Lösung finden können, ist das in Ordnung für mich, mach es einfach 👍

@andrewcmyers Nun, vielleicht war "erfunden" ein bisschen weit hergeholt, das ist wahrscheinlich eher wie David Musser im Jahr 1971, der später mit Stepanov an einigen generischen Bibliotheken für Ada arbeitete.

Elements of Programming ist kein Buch über C++, die Beispiele mögen in C++ sein, aber das ist etwas ganz anderes. Ich denke, dieses Buch ist eine unverzichtbare Lektüre für jeden, der Generika in jeder Sprache implementieren möchte. Bevor Sie Stepanov entlassen, sollten Sie das Buch wirklich lesen, um zu sehen, worum es eigentlich geht.

Dieses Problem stößt bereits an die Grenzen der GitHub-Skalierbarkeit. Bitte konzentrieren Sie die Diskussion hier auf konkrete Themen für Go-Vorschläge.

Es wäre unglücklich, wenn Go der C++-Route folgen würde.

@andrewcmyers Ja, ich stimme voll und ganz zu, bitte verwenden Sie C++ nicht für Syntaxvorschläge oder als Maßstab für die richtige Vorgehensweise. Schauen Sie sich stattdessen bitte D an, um sich inspirieren zu lassen .

@nomad-software

Ich mag D sehr, aber braucht go die mächtigen Meta-Programmierfunktionen zur Kompilierzeit, die D bietet?

Auch in C++ gefällt mir die Template-Syntax nicht, die aus der Steinzeit stammt.

Aber was ist mit dem normalen ParametricTypeStandard in Java oder C# zu finden, bei Bedarf kann man diesen auch mit ParametricType überladen

Außerdem mag ich die Template-Call-Syntax in D mit ihrem Bang-Symbol nicht, das Bang-Symbol wird heutzutage eher verwendet, um veränderlichen oder unveränderlichen Zugriff auf die Parameter einer Funktion zu bezeichnen.

@nomad-software Ich habe nicht vorgeschlagen, dass die C ++ - Syntax oder der Vorlagenmechanismus der richtige Weg ist, um Generika zu erstellen. Mehr noch, dass "Konzepte" im Sinne von Stepanov Typen als Algebra behandeln, was sehr genau der richtige Weg ist, Generika zu erstellen. Sehen Sie sich Haskell-Typklassen an, um zu sehen, wie dies aussehen könnte. Haskell-Klassen sind semantisch sehr nah an C++-Vorlagen und -Konzepten, wenn Sie verstehen, was vor sich geht.

Also +1 für die Nichtbefolgung der C++-Syntax und +1 für die Nichtimplementierung eines typunsicheren Vorlagensystems :-)

@keean Der Grund für die D-Syntax besteht darin, <,> insgesamt zu vermeiden und die kontextfreie Grammatik einzuhalten. Dies ist Teil meines Punktes, D als Inspiration zu verwenden. <,> ist eine wirklich schlechte Wahl für die Syntax generischer Parameter.

@nomad-software Wie ich oben (in einem jetzt versteckten Kommentar) darauf hingewiesen habe, müssen Sie die Typparameter für parametrische Typen angeben, nicht jedoch für universell quantifizierte Typen (daher der Unterschied zwischen Rust und Haskell, die Art und Weise, wie Typen behandelt werden, ist tatsächlich unterschiedlich im Typensystem). Auch C++-Konzepte == Haskell-Typklassen == Go-Schnittstellen, zumindest auf konzeptioneller Ebene.

Ist D Syntax wirklich vorzuziehen:

auto add(T)(T lhs, T rhs) {
    return lhs + rhs;

Warum ist das besser als C++/Java/Rust-Stil:

T add<T>(T lhs, T rhs) {
    return lhs + rhs;
}

Oder Scala-Stil:

T add[T](T lhs, T rhs) {
    return lhs + rhs;
}

Ich habe über die Syntax für Typparameter nachgedacht. Ich war noch nie ein Fan von "spitzen Klammern" in C++ und Java, weil sie das Parsen ziemlich schwierig machen und damit die Entwicklung von Tools behindern. Eckige Klammern sind eigentlich eine klassische Wahl (von CLU, System F und anderen frühen Sprachen mit parametrischem Polymorphismus).

Allerdings ist die Syntax von Go ziemlich heikel, vielleicht weil sie schon so knapp ist. Mögliche Syntaxen, die auf eckigen Klammern oder runden Klammern basieren, erzeugen grammatikalische Mehrdeutigkeiten, die noch schlimmer sind als die, die durch spitze Klammern eingeführt werden. Also trotz meiner Veranlagung scheinen spitze Klammern eigentlich die beste Wahl für Go zu sein. (Natürlich gibt es auch echte spitze Klammern, die keine Mehrdeutigkeit erzeugen würden – ⟨⟩ – aber sie würden die Verwendung von Unicode-Zeichen erfordern).

Natürlich ist die genaue Syntax, die für Typparameter verwendet wird, weniger wichtig als die richtige Semantik . In diesem Punkt ist die Sprache C++ ein schlechtes Modell. Die Arbeit meiner Forschungsgruppe zu Generika in Genus (PLDI 2015) und Familia (OOPSLA 2017) bietet einen weiteren Ansatz, der Typklassen erweitert und sie mit Schnittstellen vereinheitlicht.

@andrewcmyers Ich denke, dass beide Papiere interessant sind, aber ich würde sagen, keine gute Richtung für Go, da Genus objektorientiert ist und Go nicht, und Familia vereinheitlicht Subtypisierung und parametrischen Polymorphismus, und Go hat keines von beidem. Ich denke, Go sollte einfach entweder parametrischen Polymorphismus oder universelle Quantifizierung übernehmen, es braucht keine Untertypisierung und meiner Meinung nach ist es eine bessere Sprache, um es nicht zu haben.

Ich denke, Go sollte nach Generika suchen, die keine Objektorientierung und keine Untertypisierung erfordern. Go hat bereits Schnittstellen, die meiner Meinung nach ein guter Mechanismus für Generika sind. Wenn Sie sehen können, dass Go-Schnittstellen == C++-Konzepte == Haskell-Typklassen, scheint es mir, dass der Weg, Generika hinzuzufügen, während der Geschmack von 'Go' beibehalten wird, darin besteht, Schnittstellen zu erweitern, um mehrere Typparameter zu akzeptieren (ich würde wie assoziierte Typen auch auf Schnittstellen, aber das könnte eine separate Erweiterung davon sein, hilft dabei, dass mehrere Typparameter akzeptiert werden). Das wäre die Schlüsseländerung, aber um dies zu ermöglichen, müsste es eine „alternative“ Syntax für Schnittstellen in Funktionssignaturen geben, damit Sie die mehreren Typparameter an die Schnittstellen übertragen können, wo die gesamte Syntax der spitzen Klammern ins Spiel kommt .

Go-Schnittstellen sind keine Typklassen – sie sind lediglich Typen – aber Familia zeigt einen Weg, Schnittstellen mit Typklassen zu vereinheitlichen. Die Mechanismen von Genus und Familia sind nicht daran gebunden, dass die Sprachen vollständig objektorientiert sind. Go-Schnittstellen machen Go bereits in der wichtigen Weise "objektorientiert", daher denke ich, dass die Ideen in leicht vereinfachter Form angepasst werden könnten.

@andrewcmyers

Go-Schnittstellen sind keine Typklassen – sie sind lediglich Typen

Sie verhalten sich für mich nicht wie Typen, da sie Polymorphismus zulassen. Das Objekt in einem polymorphen Array wie Addable[] hat immer noch seinen tatsächlichen Typ (sichtbar durch Reflektion zur Laufzeit), daher verhalten sie sich genau wie Klassen mit Einzelparametertyp. Die Tatsache, dass sie in Typsignaturen an die Stelle eines Typs gesetzt werden, ist einfach eine Kurzschreibweise, bei der die Typvariable weggelassen wird. Verwechseln Sie die Notation nicht mit der Semantik.

f(x : Addable) == f<T>(x : T) requires Addable<T>

Diese Identität gilt natürlich nur für Einzelparameterschnittstellen.

Der einzige signifikante Unterschied zwischen Schnittstellen und Einzelparameter-Typklassen besteht darin, dass Schnittstellen lokal definiert werden, aber das ist nützlich, weil es das globale Kohärenzproblem vermeidet, das Haskell mit seinen Typklassen hat. Ich denke, das ist ein interessanter Punkt im Designbereich. Schnittstellen mit mehreren Parametern würden Ihnen die gesamte Leistungsfähigkeit von Typklassen mit mehreren Parametern mit dem Vorteil geben, lokal zu sein. Es besteht keine Notwendigkeit, der Go-Sprache irgendeine Vererbung oder Untertypisierung hinzuzufügen (was meiner Meinung nach die beiden Hauptmerkmale sind, die OO definieren).

MEINER BESCHEIDENEN MEINUNG NACH:

Immer noch einen Standardtyp zu haben, wäre einer DSL vorzuziehen, die dazu bestimmt ist, Typbeschränkungen auszudrücken. Als hätte man eine Funktion f(s T fmt.Stringer) , die eine generische Funktion ist, die jeden Typ akzeptiert, der auch die Schnittstelle fmt.Stringer erfüllt/befriedigt.

Auf diese Weise ist es möglich, eine generische Funktion zu haben wie:

func add(a, b T int) T int {
    return a + b
}

Jetzt funktioniert die Funktion add() mit jedem Typ T , der wie int #$ den Operator + unterstützt.

@dc0d Ich stimme zu, dass dies angesichts der aktuellen Go-Syntax attraktiv erscheint. Es ist jedoch nicht „vollständig“, da es nicht alle für Generika notwendigen Einschränkungen darstellen kann, und es wird noch Bestrebungen geben, dies weiter auszubauen. Dies wird zu einer Vermehrung verschiedener Syntaxen führen, die meiner Ansicht nach im Widerspruch zum Ziel der Einfachheit stehen. Ich bin der Meinung, dass Einfachheit nicht einfach ist, sie muss die einfachste sein, aber dennoch die erforderliche Ausdruckskraft bieten. Derzeit sehe ich die größte Einschränkung von Go in Bezug auf die generische Ausdruckskraft im Fehlen von Schnittstellen mit mehreren Parametern. Beispielsweise könnte eine Collection-Schnittstelle wie folgt definiert werden:

type T U Collection interface {
   member(c T, v U) Bool
   insert(c T, v U) T
}

Das macht also Sinn oder? Wir würden gerne Schnittstellen über Dinge wie Sammlungen schreiben. Die Frage ist also, wie Sie diese Schnittstelle in einer Funktion verwenden. Mein Vorschlag wäre so etwas wie:

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
}

Die Syntax ist nur ein Vorschlag, aber ich habe nichts dagegen, was die Syntax ist, solange Sie diese Konzepte in der Sprache ausdrücken können.

@keean Es wäre nicht korrekt, wenn ich sagen würde, dass mir die Syntax überhaupt nichts ausmacht. Aber der Punkt war die Betonung darauf, einen Standardtyp für jeden generischen Parameter zu haben. In diesem Sinne wird das bereitgestellte Beispiel für die Schnittstelle zu:

type Collection interface (T interface{}, U interface{}) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

Jetzt hilft der Teil (T interface{}, U interface{}) beim Definieren von Einschränkungen. Wenn die Mitglieder zum Beispiel fmt.Stringer erfüllen sollen, dann wäre die Definition:

type Collection interface (T fmt.Stringer, U fmt.Stringer) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

@dc0d Dies wäre wiederum in dem Sinne restriktiv, dass Sie durch mehr als einen Typparameter einschränken möchten, beachten Sie:

type OrderedCollection[T, U] interface
   requires Collection[T, U], Ord[U] {...}

Ich glaube, ich sehe, woher Sie mit der Parameterplatzierung kommen, Sie könnten Folgendes haben:

type OrderedCollection interface(T, U)
   requires Collection(T, U), Ord(U) {...}

Wie gesagt, mich stört die Syntax nicht allzu sehr, da ich mich an die meisten Syntaxen gewöhnen kann. Aus dem Obigen nehme ich an, dass Sie Klammern '()' für Schnittstellen mit mehreren Parametern bevorzugen.

@keean Betrachten wir die Schnittstelle heap.Interface . Aktuelle Definition in der Standardbibliothek ist:

type Interface interface {
    sort.Interface
    Push(x interface{}) // add x as element Len()
    Pop() interface{}   // remove and return element Len() - 1.
}

Lassen Sie uns es jetzt als generische Schnittstelle umschreiben und den Standardtyp verwenden:

type Interface interface (T interface{}) {
    sort.Interface
    Push(x T) // add x as element Len()
    Pop() T   // remove and return element Len() - 1.
}

Dies bricht keine der Go 1.x-Codeserien da draußen. Eine Implementierung wäre mein Vorschlag für Type Alias ​​Rebinding. Aber ich bin mir sicher, dass es bessere Implementierungen geben kann.

Mit Standardtypen können wir generischen Code schreiben, der mit Code im Go 1.x-Stil verwendet werden kann. Und die Standardbibliothek kann zu einer generischen Bibliothek werden, ohne etwas zu beschädigen. Das ist großer Gewinn IMO.

@dc0d Sie schlagen also eine schrittweise Verbesserung vor? Was Sie vorschlagen, sieht für mich als inkrementelle Verbesserung gut aus, hat jedoch immer noch eine begrenzte generische Ausdruckskraft. Wie würden Sie die Schnittstellen "Collection" und "OrderedCollection" implementieren?

Bedenken Sie, dass mehrere partielle Spracherweiterungen zu einem komplexeren Endprodukt (mit mehreren alternativen Syntaxen) führen können, als wenn Sie die vollständige Lösung so einfach wie möglich implementieren.

@keean Ich verstehe den Teil requires Collection[T, U], Ord[U] nicht. Wie beschränken sie die Typparameter T und U ?

@dc0d Sie funktionieren genauso wie in einer Funktion, gelten aber für alles. Für jedes Paar von Typen TU, die eine OrderedCollection sind, müssen wir also TU auch eine Instanz von Collection und U Ord sein. Überall dort, wo wir also OrderedCollection verwenden, können wir gegebenenfalls Methoden aus Collection und Ord verwenden.

Wenn wir minimalistisch sind, sind diese nicht erforderlich, da wir die zusätzlichen Schnittstellen in die Funktionstypen aufnehmen können, wo wir sie benötigen, zum Beispiel:

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)
{...}

Aber vielleicht besser lesbar:

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) Solange es einen obligatorischen Standardwert für die Typparameter gibt, bin ich glücklich. Auf diese Weise ist es möglich, die Abwärtskompatibilität mit der Codeserie Go 1.x aufrechtzuerhalten. Das ist der Hauptpunkt, den ich versucht habe zu machen.

@Keean

Go-Schnittstellen sind keine Typklassen – sie sind lediglich Typen

Sie verhalten sich für mich nicht wie Typen, da sie Polymorphismus zulassen.

Ja, sie erlauben Subtyp-Polymorphismus . Go hat Subtyping über Schnittstellentypen. Es hat keine explizit deklarierten Subtyp-Hierarchien, aber das ist weitgehend orthogonal. Was Go nicht vollständig objektorientiert macht, ist die fehlende Vererbung.

Alternativ können Sie Schnittstellen als existenziell quantifizierte Anwendungen von Typklassen betrachten. Ich glaube, das haben Sie im Sinn. Das haben wir in Genus und Familia gemacht.

@andrewcmyers

Ja, sie erlauben Subtyp-Polymorphismus.

Soweit ich weiß, ist es invariant, es gibt keine Kovarianz oder Kontravarianz, dies spricht stark dafür, dass dies keine Subtypisierung ist. Polymorphe Typsysteme sind unveränderlich, daher scheint mir Go diesem Modell näher zu sein, und die Behandlung von Schnittstellen als Einzelparameter-Typklassen scheint eher der Einfachheit von Go zu entsprechen. Das Fehlen von Kovarianz und Kontravarianz ist ein großer Vorteil für Generika, sehen Sie sich nur die Verwirrung an, die solche Dinge in Sprachen wie C# verursachen:

https://docs.microsoft.com/en-us/dotnet/standard/generics/covariance-and-contravariance

Ich denke, Go sollte diese Art von Komplexität vollständig vermeiden. Für mich bedeutet dies, dass wir Generics und Subtyping nicht im selben Typsystem haben wollen.

Alternativ können Sie Schnittstellen als existenziell quantifizierte Anwendungen von Typklassen betrachten. Ich glaube, das haben Sie im Sinn. Das haben wir in Genus und Familia gemacht.

Da Go zur Laufzeit über Typinformationen verfügt, ist keine existenzielle Quantifizierung erforderlich. In Haskell sind Typen unboxed (wie native 'C'-Typen) und das bedeutet, sobald wir etwas in eine existenzielle Sammlung eingefügt haben, können wir den Typ des Inhalts nicht (leicht) wiederherstellen, alles, was wir tun können, ist die bereitgestellten Schnittstellen (Typ-Klassen ). Dies wird dadurch realisiert, dass neben den Rohdaten ein Zeiger auf die Schnittstellen gespeichert wird. In Go wird stattdessen der Datentyp gespeichert, die Daten sind „Boxed“ (wie in C# Boxed- und Unboxed-Daten). Als solches ist Go nicht nur auf die mit den Daten gespeicherten Schnittstellen beschränkt, da es möglich ist (durch Verwendung eines Type-Case), den Typ der Daten in der Sammlung wiederherzustellen, was nur in Haskell möglich ist, indem eine „Reflection“ implementiert wird. typeclass (obwohl es umständlich ist, die Daten herauszubekommen, ist es möglich, den Typ und die Daten zu serialisieren, um Strings zu sagen, und dann außerhalb der existentiellen Box zu deserialisieren). Meine Schlussfolgerung ist also, dass sich Go-Schnittstellen genau so verhalten, wie es Typklassen tun würden, wenn Haskell die Typklasse „Reflection“ als eingebaute Funktion bereitstellen würde. Als solches gibt es keine existenzielle Box, und wir können immer noch den Inhalt von Sammlungen typisieren, aber Schnittstellen verhalten sich genau wie Typklassen. Der Unterschied zwischen Haskell und Go liegt in der Semantik von geschachtelten und nicht geschachtelten Daten, und Schnittstellen sind Typklassen mit einzelnen Parametern. Wenn 'Go' eine Schnittstelle als Typ behandelt, tut es tatsächlich Folgendes:

Addable[] == exists T . T[] requires Addable[T], Reflection[T]

Es ist wahrscheinlich erwähnenswert, dass dies die gleiche Art und Weise ist, wie "Eigenschaftsobjekte" in Rust funktionieren.

Go kann Existenzialien (für den Programmierer sichtbar sein), Kovarianz und Kontravarianz vollständig vermeiden, was eine gute Sache ist, und das wird meiner Meinung nach Generika viel einfacher und leistungsfähiger machen.

Soweit ich weiß, ist es invariant, es gibt keine Kovarianz oder Kontravarianz, dies spricht stark dafür, dass dies keine Subtypisierung ist.

Polymorphe Typsysteme sind unveränderlich, daher scheint es mir näher an diesem Modell zu liegen, und die Behandlung von Schnittstellen als Einzelparameter-Typklassen scheint eher der Einfachheit von Go zu entsprechen.

Darf ich vorschlagen, dass Sie beide Recht haben? Insofern sind Schnittstellen äquivalent zu Typklassen, aber Typklassen sind eine Form der Untertypisierung. Die Definitionen der Subtypisierung, die ich bisher gefunden habe, sind alle ziemlich vage und ungenau und laufen auf "A ist ein Subtyp von B, wenn einer durch den anderen ersetzt werden kann" hinaus. Was meiner Meinung nach ziemlich leicht durch Typklassen befriedigt werden kann.

Beachten Sie, dass das Varianz-Argument an sich meiner Meinung nach nicht wirklich funktioniert. Varianz ist eine Eigenschaft von Typkonstruktoren, keine Sprache. Und es ist ziemlich normal, dass nicht alle Typkonstruktoren in einer Sprache variabel sind (z. B. haben viele Sprachen mit Subtypisierung veränderliche Arrays, die invariant sein müssen, um typsicher zu sein). Ich verstehe also nicht, warum Sie ohne Variantentypkonstruktoren keine Subtypisierung haben könnten.

Außerdem glaube ich, dass diese Diskussion für ein Problem im Go-Repository etwas zu weit gefasst ist. Hier sollte es nicht darum gehen, die Feinheiten von Typtheorien zu diskutieren, sondern darum, ob und wie Generika zu Go hinzugefügt werden können.

@Merovius- Varianz ist eine Eigenschaft, die der Untertypisierung zugeordnet ist. In Sprachen ohne Subtypisierung gibt es keine Varianz. Damit es überhaupt Varianz gibt, müssen Sie Subtyping haben, was das Kovarianz/Kontravarianz-Problem für Typkonstruktoren einführt. Sie haben jedoch Recht, dass es in einer Sprache mit Subtypisierung möglich ist, dass alle Typkonstruktoren invariant sind.

Typklassen sind definitiv keine Subtypen, da eine Typklasse kein Typ ist. Wir können 'Schnittstellentypen' in Go jedoch als das betrachten, was Rust ein 'Eigenschaftsobjekt' nennt, effektiv ein Typ, der von der Typklasse abgeleitet ist.

Die Semantik von Go scheint im Moment zu beiden Modellen zu passen, da es keine Varianz und implizite „Eigenschaftsobjekte“ gibt. Vielleicht ist Go also an einem Wendepunkt, Generika und das Typsystem könnten entlang der Linien der Subtypisierung entwickelt werden, Varianz einführen und am Ende so etwas wie Generika in C# haben. Alternativ könnte Go Schnittstellen mit mehreren Parametern einführen, die Schnittstellen für Sammlungen ermöglichen, und dies würde die unmittelbare Verbindung zwischen Schnittstellen und „Schnittstellentypen“ aufheben. Zum Beispiel, wenn Sie haben:

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[] {...}

Es gibt keine offensichtliche Untertypbeziehung mehr zwischen den Typen T, U und der Schnittstelle Collection. Daher können Sie die Beziehung zwischen dem Instanztyp und den Schnittstellentypen nur als Untertypisierung für den Spezialfall von Einzelparameterschnittstellen betrachten, und wir können keine Abstraktionen von Dingen wie Sammlungen mit Einzelparameterschnittstellen ausdrücken.

Ich denke, für Generika muss man eindeutig in der Lage sein, Dinge wie Sammlungen zu modellieren, daher sind Schnittstellen mit mehreren Parametern ein Muss für mich. Ich denke jedoch, dass die Wechselwirkung zwischen Kovarianz und Kontravarianz in Generika ein übermäßig komplexes Typsystem schafft, daher möchte ich Subtypen vermeiden.

@keean Da Schnittstellen als Typen verwendet werden können und Typklassen keine Typen sind, ist die natürlichste Erklärung der Go-Semantik, dass Schnittstellen keine Typklassen sind. Ich verstehe, dass Sie argumentieren, Schnittstellen als Typklassen zu verallgemeinern; Ich denke, es ist eine vernünftige Richtung, die Sprache zu nehmen, und tatsächlich haben wir diesen Ansatz bereits ausführlich in unserer veröffentlichten Arbeit untersucht.

Um festzustellen, ob Go Subtyping hat, beachten Sie bitte den folgenden Code:

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")
}

Die Zuordnung von x zu y zeigt, dass der Typ von y verwendet werden kann, wo der Typ von x erwartet wird. Dies ist eine Subtypisierungsbeziehung, nämlich: CloneableZ <: Cloneable und auch S <: CloneableZ . Selbst wenn Sie Schnittstellen in Bezug auf Typklassen erklärt haben, wäre hier immer noch eine Subtypisierungsbeziehung im Spiel, etwa S <: ∃T.CloneableZ[T] <: ∃T.Cloneable[T] .

Beachten Sie, dass es für Go absolut sicher wäre, der Funktion Clone zu erlauben, ein S zurückzugeben, aber Go erzwingt zufälligerweise unnötig restriktive Regeln für die Konformität mit Schnittstellen: tatsächlich dieselben Regeln wie Java ursprünglich durchgesetzt. Die Untertypisierung erfordert keine nicht-invarianten Typkonstruktoren, wie @Merovius beobachtet hat.

@andrewcmyers Was passiert mit Schnittstellen mit mehreren Parametern, wie sie zum Abstrahieren von Sammlungen erforderlich sind?

Darüber hinaus kann die Zuweisung von x nach y als Demonstration der Schnittstellenvererbung ohne jegliche Untertypisierung angesehen werden. In Haskell (das eindeutig keine Untertypisierung hat) würden Sie schreiben:

class Cloneable t => CloneableZ t where...

Wo wir x haben, ist ein Typ, der CloneableZ implementiert, der per Definition auch Cloneable implementiert, also offensichtlich y zugewiesen werden kann.

Zusammenfassend lässt sich sagen, dass Sie entweder eine Schnittstelle als Typ und Go betrachten können, um eine begrenzte Untertypisierung ohne kovariante oder kontravariante Typkonstruktoren zu haben, oder Sie können sie als "Eigenschaftsobjekt" betrachten, oder vielleicht würden wir sie in Go als " Schnittstellenobjekt", das effektiv ein polymorpher Container ist, der durch eine Schnittstellen-"Typklasse" eingeschränkt wird. Im Typklassenmodell gibt es keine Subtypisierung und daher keinen Grund, sich Gedanken über Kovarianz und Kontravarianz zu machen.

Wenn wir beim Subtyping-Modell bleiben, können wir keine Sammlungstypen haben, deshalb musste C++ Templates einführen, weil die objektorientierte Subtypisierung nicht ausreicht, um Konzepte wie Container generisch zu definieren. Am Ende haben wir zwei Mechanismen für die Abstraktion, Objekte und Subtypisierung sowie Templates/Traits und Generika, und die Interaktionen zwischen den beiden werden komplex, sehen Sie sich zum Beispiel C++, C# und Scala an. Es wird weiterhin Forderungen geben, kovariante und kontravariante Konstruktoren einzuführen, um die Leistungsfähigkeit von Generika im Einklang mit diesen anderen Sprachen zu erhöhen.

Wenn wir generische Sammlungen wollen, ohne ein separates generisches System einzuführen, dann sollten wir an Schnittstellen wie Typklassen denken. Schnittstellen mit mehreren Parametern würden bedeuten, nicht mehr über Subtypisierung nachzudenken und stattdessen über Schnittstellenvererbung nachzudenken. Wenn wir Generika in Go verbessern und Abstraktionen von Dingen wie Sammlungen zulassen wollen und wir nicht die Komplexität der Typsysteme von Sprachen wie C++, C#, Scala usw. wollen, dann sind Multiparameter-Schnittstellen und Schnittstellenvererbung der Weg gehen.

@Keean

Was passiert mit Schnittstellen mit mehreren Parametern, wie sie zum Abstrahieren von Sammlungen erforderlich sind?

Bitte lesen Sie unsere Artikel zu Genus und Familia, die Multiparameter-Type Constraints unterstützen. Familia vereinheitlicht diese Einschränkungen mit Schnittstellen und ermöglicht Schnittstellen, mehrere Typen einzuschränken.

Wenn wir beim Subtyping-Modell bleiben, können wir keine Sammlungstypen haben

Ich bin mir nicht ganz sicher, was Sie mit "dem Subtyping-Modell" meinen, aber es ist ziemlich klar, dass Java und C # Sammlungstypen haben, daher ergibt diese Behauptung für mich keinen Sinn.

Wo wir haben, ist x ein Typ, der CloneableZ implementiert, das per Definition auch Cloneable implementiert, also offensichtlich y zugewiesen werden kann.

Nein, in meinem Beispiel ist x eine Variable und y eine andere Variable. Wenn ich weiß, dass y ein Typ CloneableZ ist und x ein Typ Cloneable ist, bedeutet das nicht, dass ich von y zu x zuweisen kann. Das tut mein Beispiel.

Um zu verdeutlichen, dass zum Modellieren von Go eine Untertypisierung erforderlich ist, finden Sie unten eine geschärfte Version des Beispiels, dessen moralisches Äquivalent in Haskell keine Typprüfung durchführt. Das Beispiel zeigt, dass die Subtypisierung die Erstellung heterogener Sammlungen ermöglicht, in denen verschiedene Elemente unterschiedliche Implementierungen haben. Darüber hinaus ist die Menge möglicher Implementierungen offen.

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

Ich bin mir nicht ganz sicher, was Sie mit "dem Subtyping-Modell" meinen, aber es ist ziemlich klar, dass Java und C # Sammlungstypen haben, daher ergibt diese Behauptung für mich keinen Sinn.

Sehen Sie sich an, warum C++ Vorlagen entwickelt hat, das OO-Subtypisierungsmodell war nicht in der Lage, die generischen Konzepte auszudrücken, die für die Verallgemeinerung von Dingen wie Sammlungen erforderlich sind. C# und Java mussten auch ein vollständiges generisches System getrennt von Objekten, Subtypisierung und Vererbung einführen und dann das Durcheinander der komplexen Interaktionen der beiden Systeme mit Dingen wie kovarianten und kontravarianten Typkonstruktoren aufräumen. Im Nachhinein können wir die OO-Subtypisierung vermeiden und uns stattdessen ansehen, was passiert, wenn wir Schnittstellen (Typklassen) zu einer einfach typisierten Sprache hinzufügen. Dies ist, was Rust getan hat, also lohnt es sich, einen Blick darauf zu werfen, aber natürlich wird es durch die ganze Lebenszeit kompliziert. Go hat GC, also hätte es nicht diese Komplexität. Mein Vorschlag ist, dass Go erweitert werden kann, um Schnittstellen mit mehreren Parametern zu ermöglichen und diese Komplexität zu vermeiden.

In Bezug auf Ihre Behauptung, dass Sie dieses Beispiel nicht in Haskell ausführen können, hier ist der Code:

{-# 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)

Einige interessante Unterschiede, Go leitet diesen Typ data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a automatisch ab, da Sie auf diese Weise eine Schnittstelle (die keinen Speicher hat) in einen Typ (der Speicher hat) umwandeln. Rust leitet diese Typen ebenfalls ab und nennt sie "Trait-Objekte". . In anderen Sprachen wie Java, C# und Scala stellen wir fest, dass Sie Schnittstellen nicht instanziieren können, was eigentlich "richtig" ist, Schnittstellen sind keine Typen, sie haben keinen Speicher, Go leitet den Typ eines existenziellen Containers automatisch für Sie ab, damit Sie ihn behandeln können die Schnittstelle wie einen Typ, und Go verbirgt dies vor Ihnen, indem es dem existenziellen Container denselben Namen gibt wie der Schnittstelle, von der er abgeleitet ist. Die andere zu beachtende Sache ist, dass dieses [2]Cloneable{x, y} alle Mitglieder zu Cloneable $ zwingt, während Haskell keine solchen impliziten Zwänge hat und wir die Mitglieder explizit mit ToCloneable zwingen müssen .

Ich wurde auch darauf hingewiesen, dass wir S und T nicht als Subtypen von Cloneable betrachten sollten, da S und T keine sind baulich kompatibel. Wir können buchstäblich jeden Typ als Instanz von Cloneable deklarieren (indem Sie einfach die relevante Definition der Funktion clone in Go deklarieren), und diese Typen müssen überhaupt keine Beziehung zueinander haben.

Die meisten Vorschläge für Generics scheinen zusätzliche Token zu enthalten, was meiner Meinung nach die Lesbarkeit und das einfache Gefühl von Go beeinträchtigt. Ich würde gerne eine andere Syntax vorschlagen, von der ich denke, dass sie möglicherweise gut mit der vorhandenen Grammatik von Go funktionieren könnte (es passiert sogar, dass die Syntaxhervorhebung in Github Markdown ziemlich gut funktioniert).

Die wichtigsten Punkte des Vorschlags:

• Die Grammatik von Go scheint immer eine einfache Möglichkeit zu haben, um festzustellen, wann eine Typdeklaration beendet ist, weil es ein bestimmtes Token oder Schlüsselwort gibt, nach dem wir suchen. Wenn dies in allen Fällen zutrifft, können Typargumente einfach nach den Typnamen selbst hinzugefügt werden.
• Wie bei den meisten Vorschlägen bedeutet derselbe Bezeichner in jeder Funktionsdeklaration denselben Typ. Diese Bezeichner entkommen niemals der Deklaration.
• In den meisten Vorschlägen müssen Sie generische Typargumente deklarieren, aber in diesem Vorschlag ist dies implizit. Einige Leute werden behaupten, dass dies die Lesbarkeit oder Klarheit beeinträchtigt (Implizitheit ist schlecht) oder die Fähigkeit einschränkt, einen Typ zu benennen, es folgen Widerlegungen:
  
  
  
  • Wenn es darum geht, die Lesbarkeit zu beeinträchtigen, kann man meiner Meinung nach so oder so argumentieren, das Extraoder [T] beeinträchtigt die Lesbarkeit genauso, indem es viel syntaktisches Rauschen verursacht.
  
  
  • Implizitheit kann bei richtiger Anwendung dazu beitragen, dass eine Sprache weniger ausführlich ist. Wir verzichten ständig auf Typdeklarationen mit := , weil die dadurch verborgenen Informationen einfach nicht wichtig genug sind, um sie jedes Mal zu buchstabieren.
  
  
  • Die Benennung eines konkreten (nicht generischen) Typs a oder t ist wahrscheinlich eine schlechte Praxis, daher geht dieser Vorschlag davon aus, dass es sicher ist, diese Bezeichner als generische Typargumente zu reservieren. Obwohl dies vielleicht eine Go-Fix-Migration erfordern würde?
  
  

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
}

Dies stammt aus einem Gist, der etwas mehr Details sowie hier vorgeschlagene Summentypen enthält: https://gist.github.com/aarondl/9b950373642fcf5072942cf0fca2c3a2

Dies ist kein vollständig ausgespülter Generika-Vorschlag und soll es auch nicht sein, es gibt eine Menge Probleme zu lösen, um Generika zu Go hinzufügen zu können. Dieser befasst sich nur mit der Syntax, und ich hoffe, wir können uns darüber unterhalten, ob das, was vorgeschlagen wird, machbar / wünschenswert ist oder nicht.

@aarondl
Sieht für mich gut aus, mit dieser Syntax hätten wir:

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 Würden Sie bitte den Typ Collection etwas erklären. Ich verstehe es nicht:

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

@dc0d Collection ist eine Schnittstelle, die _alle_ Sammlungen abstrahiert, also Bäume, Listen, Slices usw., sodass wir generische Operationen wie member und insert haben können, die mit jeder Sammlung funktionieren, die einen beliebigen Datentyp enthält. Oben habe ich das Beispiel für die Definition von „insert“ für den LinkedList-Typ im vorherigen Beispiel gegeben:

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

Wir könnten es auch für ein Slice definieren

func insert(c []a, e a) []a {
   return append(c, e)
}

Wir brauchen jedoch nicht einmal die Art von parametrischen Funktionen mit Typvariablen, wie sie von @aarondl mit dem polymorphen Typ a veranschaulicht werden, damit dies funktioniert, da Sie einfach für konkrete Typen definieren können:

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 ist also eine Schnittstelle zur Verallgemeinerung sowohl des Typs eines Containers als auch des Typs seines Inhalts, wodurch generische Funktionen geschrieben werden können, die auf alle Kombinationen von Container und Inhalt wirken.

Es gibt keinen Grund, warum Sie nicht auch einen Teil der Sammlungen []Collection haben könnten, in denen die Inhalte alle unterschiedliche Sammlungstypen mit unterschiedlichen Wertetypen wären, vorausgesetzt, dass member und insert für jede Kombination definiert wurden .

@aarondl Angesichts der Tatsache, dass type LinkedList a bereits eine gültige Typdeklaration ist, sehe ich nur zwei Möglichkeiten, dies eindeutig parsbar zu machen: Die Grammatik kontextsensitiv machen (in die Probleme beim Analysieren von C einsteigen, ugh) oder unbegrenztes Lookahead verwenden ( was die Go-Grammatik aufgrund schlechter Fehlermeldungen im Fehlerfall eher vermeidet). Ich verstehe vielleicht etwas falsch, aber meiner Meinung nach spricht das gegen einen tokenlosen Ansatz.

@keean Schnittstellen in Go verwenden Methoden, keine Funktionen. In der von Ihnen vorgeschlagenen spezifischen Syntax gibt es nichts, was insert *LinkedList anfügt (in Haskell geschieht dies über instance -Deklarationen). Es ist auch normal, dass Methoden den Wert verändern, mit dem sie arbeiten. Nichts davon ist ein Show-Stopper, sondern weist nur darauf hin, dass die von Ihnen vorgeschlagene Syntax mit Go nicht gut funktioniert. Wahrscheinlich eher so etwas wie

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

Dies zeigt auch ein paar weitere Fragen in Bezug darauf, wie die Typparameter abgegrenzt sind und wie diese analysiert werden sollten.

@aarondl , es gibt auch noch weitere Fragen, die ich zu deinem Vorschlag hätte. Beispielsweise sind keine Einschränkungen zulässig, sodass Sie nur uneingeschränkten Polymorphismus erhalten. Was im Allgemeinen nicht wirklich nützlich ist , da Sie mit den Werten, die Sie erhalten, nichts tun dürfen (zB Sie könnten Collection nicht mit einer Map implementieren, da nicht alle Typen gültige Map-Schlüssel sind). Was soll passieren, wenn jemand versucht, so etwas zu tun? Wenn es sich um einen Kompilierungsfehler handelt, beschwert er sich über die Instanziierung (C++-Fehlermeldungen voraus) oder über die Definition (man kann im Grunde nichts tun, weil es nichts gibt, das mit allen Typen funktioniert)?

@keean Ich verstehe immer noch nicht, wie a darauf beschränkt ist, eine Liste (oder ein Slice oder eine andere Sammlung) zu sein. Ist das eine kontextabhängige Spezialgrammatik für Sammlungen? Wenn ja, welchen Wert hat es? Es ist nicht möglich, benutzerdefinierte Typen auf diese Weise zu deklarieren.

@Merovius Bedeutet das, dass Go keinen Mehrfachversand durchführen kann und das erste Argument einer 'Funktion' zu etwas Besonderem macht? Dies deutet darauf hin, dass zugeordnete Typen besser geeignet wären als Schnittstellen mit mehreren Parametern. Etwas wie das:

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) {...}

Dies hat jedoch immer noch Probleme, da es nichts gibt, was die beiden Sammlungen dazu zwingt, derselbe Typ zu sein ... Sie würden am Ende so etwas brauchen wie:

func[A] useIt(c A, e A.Element) requires A:Collection

Um zu versuchen, den Unterschied zu erklären, Multiparameter-Schnittstellen haben zusätzliche _Eingabe_-Typen, die an der Instanzauswahl teilnehmen (daher die Verbindung mit Mehrfachversand), während assoziierte Typen _Ausgabe_-Typen sind, nur der Empfängertyp an der Instanzauswahl teilnimmt, und dann die zugehörigen Typen hängen vom Typ des Empfängers ab.

@dc0d a und b sind Typparameter der Schnittstelle, genau wie in einer Haskell-Typklasse. Damit etwas als Collection betrachtet werden kann, muss es die Methoden definieren, die mit den Typen in der Schnittstelle übereinstimmen, wobei a und b ein beliebiger Typ sein können. Wie @Merovius jedoch betont hat, sind Go-Schnittstellen methodenbasiert und unterstützen keinen Mehrfachversand, sodass Schnittstellen mit mehreren Parametern möglicherweise nicht gut geeignet sind. Mit dem Single-Dispatch-Methodenmodell von Go scheint es besser zu passen, zugeordnete Typen in Schnittstellen anstelle von mehreren Parametern zu haben. Das Fehlen von Mehrfachversand erschwert jedoch die Implementierung von Funktionen wie unify(x, y) , und Sie müssen das Doppelversandmuster verwenden, was nicht sehr schön ist.

Um das Multi-Parameter-Ding etwas weiter zu erklären:

type Cloneable[A] interface {
   clone(x A) A
}

Hier steht a für einen beliebigen Typ, es ist uns egal, was es ist, solange die richtigen Funktionen definiert sind, betrachten wir es als Cloneable . Wir würden Schnittstellen als Einschränkungen für Typen und nicht als Typen selbst betrachten.

func clone(x int) int {...}

im Fall von „Klon“ ersetzen wir in der Schnittstellendefinition a durch int , und wir können Klon aufrufen, wenn die Ersetzung erfolgreich ist. Das passt gut zu dieser Notation:

func[A] test(x A) A requires Cloneable[A] {...}

Dies ist äquivalent zu:

type Cloneable interface {
   clone() Cloneable
}

aber deklariert eine Funktion, keine Methode, und kann mit mehreren Parametern erweitert werden. Wenn Sie eine Sprache mit Mehrfachversand haben, ist das erste Argument einer Funktion/Methode nichts Besonderes, also warum schreiben Sie es an einer anderen Stelle.

Da Go keinen Mehrfachversand hat, fühlt sich das alles so an, als wäre es zu viel, um es auf einmal zu ändern. Es scheint, als würden assoziierte Typen besser passen, wenn auch eingeschränkter. Dies würde abstrakte Sammlungen ermöglichen, aber keine eleganten Lösungen für Dinge wie die Vereinheitlichung.

@Merovius Vielen Dank, dass Sie sich den Vorschlag angesehen haben. Lassen Sie mich versuchen, auf Ihre Bedenken einzugehen. Ich bin traurig, dass Sie den Vorschlag abgelehnt haben, bevor wir ihn weiter diskutiert haben. Ich hoffe, ich kann Ihre Meinung ändern - oder vielleicht können Sie meine ändern :)

Unbegrenzte Vorausschau:
Wie ich im Vorschlag erwähnt habe, scheint es derzeit so, als ob die Go-Grammatik eine gute Möglichkeit hat, das "Ende" von so ziemlich allem syntaktisch zu erkennen. Und wir würden es aufgrund der impliziten generischen Argumente immer noch tun. Ein einzelner Kleinbuchstabe ist das syntaktische Konstrukt, das dieses generische Argument erzeugt - oder was auch immer wir entscheiden, um dieses Inline-Token zu erstellen, vielleicht greifen wir sogar auf ein tokenisiertes Ding wie @a im Vorschlag zurück, wenn uns die Syntax genug gefällt, aber das ist es nicht Mögliche Compiler-Schwierigkeit ohne Token, obwohl der Vorschlag viel Charme verliert, sobald Sie das tun.

Unabhängig davon ist das Problem mit type LinkedList a unter diesem Vorschlag nicht so schwer, da wir wissen, dass a ein generisches Typargument ist und dies daher mit einem Compiler-Fehler fehlschlagen würde, der dem von type LinkedList schlägt heute fehl mit: prog.go:3:16: expected type, found newline (and 1 more errors) . Der ursprüngliche Beitrag kam nicht wirklich heraus und sagte es, aber Sie dürfen keinen konkreten Typ [a-z]{1} mehr nennen, der meiner Meinung nach dieses Problem löst und ein Opfer ist, mit dem wir alle einverstanden wären machen (ich kann heute nur Nachteile beim Erstellen echter Typen mit Einzelbuchstabennamen im Go-Code sehen).

Es ist nur unbeschränkter Polymorphismus
Der Grund, warum ich jegliche Art von Merkmalen oder Einschränkungen für generische Argumente weggelassen habe, ist, dass ich der Meinung bin, dass dies die Rolle von Schnittstellen in Go ist. Wenn Sie etwas mit einem Wert tun möchten, sollte dieser Wert ein Schnittstellentyp und kein vollständig generischer Typ sein. Ich denke, dieser Vorschlag spielt auch gut mit Schnittstellen.

Bei diesem Vorschlag hätten wir immer noch das gleiche Problem wie jetzt mit Operatoren wie + , sodass Sie keine generische Addierfunktion für alle numerischen Typen erstellen könnten, aber Sie könnten eine generische Addierfunktion als Argument akzeptieren. Folgendes berücksichtigen:

func Sort(slice []a, compare func (a, a) bool) { ... }

Fragen zum Geltungsbereich

Du hast hier ein Beispiel gegeben:

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

Der Geltungsbereich dieser Bezeichner ist in der Regel an die jeweilige Deklaration/Definition gebunden, in der sie sich befinden. Sie werden nirgendwo geteilt, und ich sehe keinen Grund dafür.

@keean Das ist sehr interessant, obwohl Sie, wie andere darauf hingewiesen haben, ändern müssten, was Sie dort gezeigt haben, um die Schnittstellen tatsächlich implementieren zu können (derzeit gibt es in Ihrem Beispiel keine Methoden mit Empfängern, nur Funktionen). Ich versuche, mehr darüber nachzudenken, wie sich dies auf meinen ursprünglichen Vorschlag auswirkt.

Ein einzelner Kleinbuchstabe ist das syntaktische Konstrukt, das dieses generische Argument erzeugt

Ich fühle mich dabei nicht gut; Es erfordert je nach Kontext separate Produktionen für das, was ein Bezeichner ist, und bedeutet auch, bestimmte Bezeichner für Typen willkürlich zu verbieten. Aber es ist nicht wirklich die Zeit, über diese Details zu sprechen.

Bei diesem Vorschlag hätten wir immer noch das gleiche Problem wie jetzt mit Operatoren wie +

Ich verstehe diesen Satz nicht. Derzeit hat der +-Operator keines dieser Probleme, da die Typen seiner Operanden lokal bekannt sind und die Fehlermeldung klar und eindeutig ist und auf die Ursache des Problems hinweist. Gehe ich richtig in der Annahme, dass Sie sagen, dass Sie die Verwendung von generischen Werten verbieten möchten, die nicht für alle möglichen Typen zulässig sind (ich kann mir nicht viele solcher Operationen vorstellen)? Und einen Compilerfehler für den anstößigen Ausdruck in der generischen Funktion erstellen? Meiner Meinung nach würde das den Wert von Generika zu sehr einschränken.

Wenn Sie etwas mit einem Wert machen möchten, sollte dieser Wert ein Schnittstellentyp und kein vollständig generischer Typ sein.

Die beiden Hauptgründe, warum Menschen Generika wollen, sind Leistung (vermeiden Sie das Umschließen von Schnittstellen) und Typsicherheit (stellen Sie sicher, dass derselbe Typ an verschiedenen Stellen verwendet wird, ohne sich darum zu kümmern, um welchen es sich handelt). Dies scheint diese Gründe zu ignorieren.

Sie könnten eine generische add-Funktion als Argument akzeptieren.

Wahr. Aber ziemlich unergonomisch. Bedenken Sie, wie viele Beschwerden es über die sort -API gab. Für viele generische Container scheint die Menge an Funktionen, die der Aufrufer implementieren und übergeben müsste, unerschwinglich zu sein. Überlegen Sie, wie würde eine container/heap -Implementierung unter diesem Vorschlag aussehen und wie wäre sie in Bezug auf die Ergonomie besser als die aktuelle Implementierung? Es scheint, dass die Gewinne hier bestenfalls vernachlässigbar sind. Sie müssten mehr triviale Funktionen implementieren (und an jeder Verwendungsstelle duplizieren/referenzieren), nicht weniger.

@Merovius

Denken Sie über diesen Punkt von @aarondl nach

Sie könnten eine generische add-Funktion als Argument akzeptieren.

Es wäre besser, eine Addable-Schnittstelle zu haben, um das Überladen von Additionen zu ermöglichen, vorausgesetzt, es gibt eine Syntax zum Definieren von Infix-Operatoren:

type Addable interface {
   + (x Addable, y Addable) Addable
}

Leider funktioniert das nicht, weil es nicht ausdrückt, dass wir erwarten, dass alle Typen gleich sind. Um Addable zu definieren, bräuchten wir so etwas wie die Multi-Parameter-Schnittstellen:

type Addable[A] interface {
   + (x A, y A) A
}

Dann müssten Sie auch Go für den Mehrfachversand benötigen, was bedeuten würde, dass alle Argumente in einer Funktion wie ein Empfänger für den Schnittstellenabgleich behandelt werden. Im obigen Beispiel ist also jeder Typ Addable , wenn eine Funktion + darauf definiert ist, die die Funktionsdefinitionen in der Schnittstellendefinition erfüllt.

Aber angesichts dieser Änderungen könnte man jetzt schreiben:

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})
}

Natürlich ist das Überladen von Funktionen und das mehrfache Dispatch etwas, das die Leute in Go nie wollen, aber dann werden Dinge wie das Definieren grundlegender Arithmetik für benutzerdefinierte Typen wie Vektoren, Matrizen, komplexe Zahlen usw. immer unmöglich sein. Wie ich oben sagte, würden "assoziierte Typen" auf Schnittstellen eine gewisse Steigerung der generischen Programmierfähigkeit ermöglichen, aber keine vollständige Allgemeingültigkeit. Ist Mehrfachversand (und vermutlich Funktionsüberlastung) etwas, das jemals in Go passieren könnte?

Dinge wie das Definieren grundlegender Arithmetik für benutzerdefinierte Typen wie Vektoren, Matrizen, komplexe Zahlen usw. werden immer unmöglich sein.

Manche halten das vielleicht für ein Feature :) AFAIR, irgendwo schwirrt ein Vorschlag oder Thread herum, in dem diskutiert wird, ob es so sein sollte. FWIW, ich denke, das wandert - wieder - vom Thema ab. Das Überladen von Operatoren (oder allgemeine Ideen, wie man Go zu mehr Haskell macht) ist nicht wirklich der Sinn dieser Ausgabe :)

Ist Mehrfachversand (und vermutlich Funktionsüberlastung) etwas, das jemals in Go passieren könnte?

Sag niemals nie. Ich persönlich würde es aber nicht erwarten.

@Merovius

Manche halten das vielleicht für ein Feature :)

Sicher, und wenn Go es nicht tut, gibt es andere Sprachen, die es tun werden :-) Go muss nicht alles für alle sein. Ich habe nur versucht, in Go einen Spielraum für Generika zu schaffen. Mein Fokus liegt auf der Erstellung vollständig generischer Sprachen, da ich eine Abneigung dagegen habe, mich selbst und Textbausteine ​​zu wiederholen (und ich mag keine Makros). Wenn ich einen Cent für jedes Mal hätte, wenn ich eine verknüpfte Liste oder einen Baum in 'C' für einen bestimmten Datentyp schreiben müsste. Es macht einige Projekte für ein kleines Team tatsächlich unmöglich, da die Menge an Code im Kopf behalten werden muss, um ihn zu verstehen, und dann durch Änderungen beibehalten werden muss. Manchmal denke ich, dass Leute, die keinen Bedarf an Generika haben, einfach noch kein ausreichend großes Programm geschrieben haben. Natürlich können Sie stattdessen ein großes Team von Entwicklern an etwas arbeiten lassen und jeden Entwickler nur für einen kleinen Teil des gesamten Codes verantwortlich machen, aber ich bin daran interessiert, einen einzelnen Entwickler (oder ein kleines Team) so effektiv wie möglich zu machen.

Angesichts der Tatsache, dass das Überladen von Funktionen und der mehrfache Versand außerhalb des Geltungsbereichs liegen, und angesichts der Parsing-Probleme mit dem Vorschlag von @aarondl scheint es, dass das Hinzufügen zugeordneter Typen zu Schnittstellen und Typparametern zu Funktionen so weit ist, wie Sie möchten go mit Generika in Go.

So etwas scheint das Richtige zu sein:

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 {...}

Dann würde in der Implementierung entschieden, ob parametrische Typen oder universell quantifizierte Typen verwendet werden. Bei parametrischen Typen (wie Java) ist eine "generische" Funktion eigentlich keine Funktion, sondern eine Art typsichere Funktionsvorlage und kann als solche nicht als Argument übergeben werden, es sei denn, ihr Typparameter ist so angegeben:

f(useIt) // not okay with parametric types
f(useIt<List>) // okay with parametric types

Bei universell quantifizierten Typen können Sie useIt als Argument übergeben und es kann dann innerhalb f mit einem Typparameter versehen werden. Der Grund, parametrische Typen zu bevorzugen, liegt darin, dass Sie den Polymorphismus zur Kompilierzeit monomorphisieren können, was bedeutet, dass zur Laufzeit keine polymorphen Funktionen entwickelt werden müssen. Ich bin mir nicht sicher, ob dies bei Go ein Problem darstellt, da Go bereits Laufzeit-Dispatching auf Schnittstellen durchführt. Solange also der Typparameter für useIt Collection implementiert, können Sie zur Laufzeit an den richtigen Empfänger senden, also universell Quantifizierung ist wahrscheinlich der richtige Weg für Go.

Ich frage mich, SFINAE wird nur von @bcmills erwähnt. Nicht einmal im Vorschlag erwähnt (obwohl Sort als Beispiel da ist).
Wie könnte dann das Sort für Slice und Linkedlist aussehen?

@Keean
Ich kann nicht herausfinden, wie man mit Ihrem Vorschlag eine generische 'Slice'-Sammlung definieren würde. Sie scheinen ein 'IntSlice' zu definieren, das möglicherweise 'Collection' implementiert (obwohl Insert einen anderen Typ als den von der Schnittstelle gewünschten zurückgibt), aber das ist kein generisches 'Slice', da es nur für Ints zu sein scheint , und die Methodenimplementierungen sind nur für ints. Müssen wir eine spezifische Implementierung pro Typ definieren?

Manchmal denke ich, dass Leute, die keinen Bedarf an Generika haben, einfach noch kein ausreichend großes Programm geschrieben haben.

Ich kann Ihnen versichern, dass dieser Eindruck falsch ist. Und FWIW, ISTM, dass „die andere Seite“ „die Notwendigkeit nicht sieht“ in denselben Eimer stellt wie „den Nutzen nicht sieht“. Ich sehe den Nutzen und widerlege ihn nicht. Allerdings sehe ich die Notwendigkeit nicht wirklich. Mir geht es gut ohne, auch in großen Codebasen.

Und verwechseln Sie „zu wollen, dass sie richtig gemacht werden, und darauf hinzuweisen, wo bestehende Vorschläge nicht sind“ auch nicht mit „grundsätzlich gegen die eigentliche Idee“.

auch angesichts der Parsing-Probleme mit dem Vorschlag von @aarondl .

Wie gesagt, ich glaube nicht, dass es im Moment wirklich produktiv ist, über das Parsing-Problem zu sprechen. Parsing-Probleme können gelöst werden. Semantisch gesehen ist das Problem des eingeschränkten Polymorphismus viel schwerwiegender. IMO, das Hinzufügen von Generika ohne das ist die Mühe nicht wirklich wert.

@urandom

Ich kann nicht herausfinden, wie man mit Ihrem Vorschlag eine generische 'Slice'-Sammlung definieren würde.

Wie oben angegeben, müssten Sie immer noch eine separate Implementierung für jeden Slice-Typ definieren, aber Sie würden immer noch davon profitieren, Algorithmen in Bezug auf die generische Schnittstelle schreiben zu können. Wenn Sie eine generische Implementierung für alle Slices zulassen wollten, müssten Sie parametrisch zugeordnete Typen und Methoden zulassen. Hinweis: Ich habe den Typparameter nach dem Schlüsselwort verschoben, sodass er vor dem Empfängertyp auftritt.

type<T> []T.Element = Int

func<T> ([]T) Member(e T) Bool {...}
func<T> ([]T) Insert(e T) Collection {...}

Allerdings müssen Sie sich jetzt auch mit der Spezialisierung befassen, da jemand den zugehörigen Typ und die Methoden für das spezialisiertere []int definieren könnte und Sie sich damit befassen müssten, welche Sie verwenden. Normalerweise würden Sie sich für die spezifischere Instanz entscheiden, aber es fügt eine weitere Ebene der Komplexität hinzu.

Ich bin mir nicht sicher, wie viel Ihnen das tatsächlich bringt. Mit meinem ursprünglichen Beispiel oben können Sie generische Algorithmen schreiben, um mit der Schnittstelle auf allgemeine Sammlungen einzuwirken, und Sie müssten nur die Methoden und zugehörigen Typen für die Typen bereitstellen, die Sie tatsächlich verwenden. Der größte Vorteil für mich besteht darin, dass ich Algorithmen wie das Sortieren beliebiger Sammlungen definieren und diese Algorithmen in einer Bibliothek ablegen kann. Wenn ich dann eine Liste von "Formen" habe, muss ich nur die Sammlungsschnittstellenmethoden für meine Liste von Formen definieren, und ich kann dann jeden Algorithmus in der Bibliothek darauf anwenden. Die Schnittstellenmethoden für alle Slice-Typen definieren zu können, interessiert mich weniger und ist für Go möglicherweise zu komplex?

@Merovius

Allerdings sehe ich die Notwendigkeit nicht wirklich. Mir geht es gut ohne, auch in großen Codebasen.

Wenn Sie mit einem Programm mit 100.000 Zeilen zurechtkommen, können Sie mit 100.000 generischen Zeilen mehr erreichen als mit 100.000 nicht-generischen Zeilen (aufgrund der Wiederholung). Sie sind also vielleicht ein Super-Star-Entwickler, der mit sehr großen Codebasen umgehen kann, aber Sie würden mit einer sehr großen generischen Codebasis immer noch mehr erreichen, da Sie die Redundanz eliminieren würden. Dieses generische Programm würde sich zu einem noch größeren nicht-generischen Programm erweitern. Mir scheint nur, dass Sie Ihre Komplexitätsgrenze noch nicht erreicht haben.

Ich denke jedoch, dass Sie Recht haben, dass "Bedürfnis" zu stark ist. Ich schreibe glücklich Go-Code, mit nur gelegentlicher Frustration über den Mangel an Generika, und ich kann dies umgehen, indem ich einfach mehr Code schreibe, und in Go ist dieser Code angenehm direkt und wörtlich.

Das Fehlen eines eingeschränkten Polymorphismus ist semantisch weit schwerwiegender. IMO, das Hinzufügen von Generika ohne das ist die Mühe nicht wirklich wert.

Ich stimme dem zu.

Sie können mit 100.000 generischen Zeilen mehr erreichen als mit 100.000 nicht generischen Zeilen (aufgrund der Wiederholung)

Ich bin neugierig, wie viel % dieser Zeilen aus Ihrem hypothetischen Beispiel eine generische Funktion wären?
Meiner Erfahrung nach sind dies weniger als 2% (aus einer Codebasis mit 115k LOC), daher denke ich nicht, dass dies ein gutes Argument ist, es sei denn, Sie schreiben eine Bibliothek für "Sammlungen".

Ich wünschte, wir würden irgendwann Generika bekommen

@Keean

In Bezug auf Ihre Behauptung, dass Sie dieses Beispiel nicht in Haskell ausführen können, hier ist der Code:

Dieser Kodex ist moralisch nicht gleichwertig mit dem Kodex, den ich geschrieben habe. Es führt zusätzlich zur ICloneable-Schnittstelle einen neuen Cloneable-Wrapper-Typ ein. Der Go-Code benötigte keinen Wrapper; noch würden andere Sprachen, die Subtyping unterstützen.

@andrewcmyers

Dieser Kodex ist moralisch nicht gleichwertig mit dem Kodex, den ich geschrieben habe. Es führt zusätzlich zur ICloneable-Schnittstelle einen neuen Cloneable-Wrapper-Typ ein.

Ist es nicht das, was dieser Code tut:

type Cloneable interface {...}

Es führt einen von der Schnittstelle abgeleiteten Datentyp 'Cloneable' ein. Sie sehen das 'ICloneable' nicht, weil Sie keine Instanzdeklarationen für Schnittstellen haben, Sie deklarieren nur die Methoden.

Können Sie es als Subtypisierung betrachten, wenn die Typen, die eine Schnittstelle implementieren, nicht strukturell kompatibel sein müssen?

@keean Ich würde Cloneable nur als Typ betrachten, nicht wirklich als "Datentyp". In einer Sprache wie Java würden der Cloneable -Abstraktion im Wesentlichen keine zusätzlichen Kosten entstehen, da es im Gegensatz zu Ihrem Code keinen Wrapper geben würde.

Es scheint mir einschränkend und unerwünscht, eine strukturelle Ähnlichkeit zwischen Typen zu verlangen, die eine Schnittstelle implementieren, daher bin ich verwirrt darüber, was Sie hier denken.

@andrewcmyers
Ich verwende Typ und Datentyp austauschbar. Jeder Typ, der Daten enthalten kann, ist ein Datentyp.

weil es anders als in Ihrem Code keinen Wrapper geben würde.

Es gibt immer einen Wrapper, weil Go-Typen immer verpackt sind, also existiert der Wrapper um alles herum. Haskell benötigt den Wrapper, um explizit zu sein, da er unverpackte Typen hat.

strukturelle Ähnlichkeit zwischen Typen, die eine Schnittstelle implementieren, daher bin ich verwirrt darüber, was Sie hier denken.

Strukturelle Subtypisierung erfordert, dass die Typen „strukturell kompatibel“ sind. Da es keine explizite Typhierarchie wie in einer OO-Sprache mit Vererbung gibt, kann die Untertypisierung nicht nominal sein, also muss sie strukturell sein, wenn sie überhaupt vorhanden ist.

Ich verstehe jedoch, was Sie meinen, was ich so beschreiben würde, dass eine Schnittstelle eine abstrakte Basisklasse ist, keine Schnittstelle, mit einer Art impliziter nomineller Subtyp-Beziehung zu jedem Typ, der die erforderlichen Methoden implementiert.

Ich denke tatsächlich, dass Go im Moment zu beiden Modellen passt, und es könnte von hier aus in beide Richtungen gehen, aber ich würde vorschlagen, dass die Bezeichnung als Schnittstelle und nicht als Klasse eine Denkweise ohne Subtypisierung nahelegt.

@keean Ich verstehe deinen Kommentar nicht. Zuerst sagst du mir, dass du anderer Meinung bist und dass ich "meine Komplexitätsgrenze noch nicht erreicht habe", und dann sagst du mir, dass du zustimmst (wobei "Bedürfnis" ein zu starkes Wort ist). Ich denke auch, dass Ihr Argument trügerisch ist (Sie gehen davon aus, dass LOC das primäre Maß für die Komplexität ist und dass jede Codezeile gleich ist). Aber vor allem glaube ich nicht, dass die Frage „wer schreibt kompliziertere Programme“ wirklich eine produktive Diskussionslinie ist. Ich wollte nur klarstellen, dass das Argument "Wenn Sie nicht meiner Meinung sind, muss das bedeuten, dass Sie nicht an so schwierigen oder interessanten Problemen arbeiten" nicht überzeugend ist und nicht in gutem Glauben rüberkommt. Ich hoffe, Sie können einfach darauf vertrauen, dass die Leute Ihnen in Bezug auf die Bedeutung dieser Funktion widersprechen können, während sie gleichermaßen kompetent sind und genauso interessante Dinge tun.

@merovius
Ich sagte, Sie sind wahrscheinlich ein fähigerer Programmierer als ich und daher in der Lage, mit mehr Komplexität zu arbeiten. Ich glaube sicherlich nicht, dass Sie an weniger interessanten oder weniger komplexen Problemen arbeiten, und es tut mir leid, dass das so rübergekommen ist. Ich habe gestern versucht, einen Scanner zum Laufen zu bringen, was ein sehr uninteressantes Problem war.

Ich kann mir vorstellen, dass Generika mir helfen, komplexere Programme mit meiner begrenzten Intelligenz zu schreiben, und ich gebe auch zu, dass ich keine Generika "brauche". Es ist eine Frage des Grades. Ich kann immer noch ohne Generika programmieren, aber ich kann nicht unbedingt Software mit der gleichen Komplexität schreiben.

Ich hoffe, das beruhigt Sie, dass ich in gutem Glauben handele, ich habe hier keine versteckten Absichten, und wenn Go keine Generika einführt, werde ich sie trotzdem verwenden. Ich habe eine Meinung darüber, wie man Generika am besten herstellt, aber das ist nicht die einzige Meinung, ich kann nur aus meiner eigenen Erfahrung sprechen. Wenn ich nicht helfe, gibt es viele andere Dinge, mit denen ich meine Zeit verbringen kann, also sagen Sie einfach ein Wort, und ich werde mich auf etwas anderes konzentrieren.

@Merovius Danke für den fortgesetzten Dialog.

| Die beiden Hauptgründe, warum Menschen Generika wollen, sind Leistung (vermeiden Sie das Umschließen von Schnittstellen) und Typsicherheit (stellen Sie sicher, dass derselbe Typ an verschiedenen Stellen verwendet wird, ohne sich darum zu kümmern, um welchen es sich handelt). Dies scheint diese Gründe zu ignorieren.

Vielleicht betrachten wir das, was ich vorgeschlagen habe, ganz anders, da es aus meiner Sicht beides tut, soweit ich das beurteilen kann? Im Beispiel der verknüpften Liste gibt es kein Wrapping mit Schnittstellen und sollte daher so performant sein, als wäre es für einen bestimmten Typ von Hand geschrieben. Auf der Typsicherheitsseite ist es genauso. Können Sie hier ein Gegenbeispiel geben, damit ich verstehe, woher Sie kommen?

| Wahr. Aber ziemlich unergonomisch. Überlegen Sie, wie viele Beschwerden es über die Sortier-API gab. Für viele generische Container scheint die Menge an Funktionen, die der Aufrufer implementieren und übergeben müsste, unerschwinglich zu sein. Überlegen Sie, wie würde eine Container/Haufen-Implementierung unter diesem Vorschlag aussehen und wie wäre sie in Bezug auf die Ergonomie besser als die aktuelle Implementierung? Es scheint, dass die Gewinne hier bestenfalls vernachlässigbar sind. Sie müssten mehr triviale Funktionen implementieren (und an jeder Verwendungsstelle duplizieren/referenzieren), nicht weniger.

Mich stört das eigentlich überhaupt nicht. Ich glaube nicht, dass die Menge an Funktionen unerschwinglich wäre, aber ich bin definitiv offen für einige Gegenbeispiele. Denken Sie daran, dass die API, über die sich die Leute beschwert haben, keine Funktion war, für die Sie eine Funktion bereitstellen mussten, sondern die ursprüngliche hier: https://golang.org/pkg/sort/#Interface , wo Sie einen neuen Typ erstellen mussten, der einfach war Ihr Slice + Typ, und implementieren Sie dann 3 Methoden darauf. Angesichts der Beschwerden und der mit dieser Schnittstelle verbundenen Schmerzen wurde Folgendes erstellt: https://golang.org/pkg/sort/#Slice , ich jedenfalls habe kein Problem mit dieser API und wir würden die Leistungseinbußen davon ausgleichen Unter dem Vorschlag, den wir diskutieren, ändern wir einfach die Definition in func Slice(slice []a, less func(a, a) bool) .

In Bezug auf die container/heap -Datenstruktur muss jeder generische Vorschlag, den Sie akzeptieren, vollständig neu geschrieben werden. container/heap genau wie das Paket sort bietet nur Algorithmen auf Ihrer eigenen Datenstruktur, aber keines der Pakete besitzt jemals die Datenstruktur, weil wir sonst []interface{} und die damit verbundene Kosten. Vermutlich würden wir sie ändern, da Sie dank Generika einen Heap haben könnten, der einen Slice mit einem konkreten Typ besitzt, und dies gilt für alle Vorschläge, die ich hier gesehen habe (einschließlich meiner eigenen). .

Ich versuche, die Unterschiede in unseren Perspektiven auf das, was ich vorgeschlagen habe, auseinanderzuhalten. Und ich denke, die Wurzel der Meinungsverschiedenheit (jenseits aller persönlichen syntaktischen Vorlieben) ist, dass es keine Einschränkungen für die generischen Typen gibt. Aber ich versuche immer noch herauszufinden, was uns das bringt. Wenn die Antwort lautet, dass nichts in Bezug auf die Leistung eine Schnittstelle verwenden darf, dann kann ich hier nicht viel sagen.

Betrachten Sie die folgende Hash-Tabellendefinition:

// 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) { ... }

Wollen wir damit sagen, dass []Hasher aufgrund von Leistungs-/Speicherproblemen ein Nichtstarter ist und dass wir für eine erfolgreiche Generika-Implementierung in Go unbedingt etwas wie das Folgende haben müssen?

// 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) { ... }

Hoffentlich sehen Sie, wo ich herkomme. Aber es ist definitiv möglich, dass ich die Einschränkungen nicht verstehe, die Sie bestimmten Codes auferlegen möchten. Vielleicht gibt es Anwendungsfälle, die ich nicht berücksichtigt habe, trotzdem hoffe ich, ein umfassenderes Verständnis dafür zu bekommen, was die Anforderungen sind und wie der Vorschlag sie nicht erfüllt.

Vielleicht betrachten wir das, was ich vorgeschlagen habe, ganz anders, da es aus meiner Sicht beides tut, soweit ich das beurteilen kann?

Das "this" in dem Abschnitt, den Sie zitieren, bezieht sich auf die Verwendung von Schnittstellen. Das Problem ist nicht, dass Ihr Vorschlag dies auch nicht tut, sondern dass Ihr Vorschlag keine eingeschränkte Polymorphie zulässt, was die meisten Verwendungen für sie ausschließt. Und die Alternative, die Sie dafür vorgeschlagen haben, waren Schnittstellen, die den Kernanwendungsfall für Generika auch nicht wirklich ansprechen (wegen der beiden Dinge, die ich erwähnt habe).

Zum Beispiel erlaubte Ihr Vorschlag (wie ursprünglich geschrieben) nicht das Schreiben einer generischen Karte jeglicher Art, da dies erfordern würde, zumindest Schlüssel mit == vergleichen zu können (was eine Einschränkung darstellt, also implementieren Sie a Karte erfordert eingeschränkten Polymorphismus).

Angesichts der Beschwerden und der mit dieser Schnittstelle verbundenen Schmerzen wurde Folgendes erstellt: https://golang.org/pkg/sort/#Slice

Beachten Sie, dass diese Schnittstelle in Ihrem Vorschlag für Generika immer noch nicht möglich ist, da sie auf Reflektion für Länge und Austausch angewiesen ist (also haben Sie auch hier eine Einschränkung für Slice-Operationen). Selbst wenn wir diese API als die untere Grenze dessen akzeptieren, was Generika leisten können sollten (viele Leute würden das nicht tun. Es gibt immer noch viele Beschwerden über die mangelnde Typsicherheit in dieser API), würde Ihr Vorschlag nicht durchkommen diese Stange.

Aber Sie zitieren auch wieder eine Antwort auf einen bestimmten Punkt, den Sie gemacht haben, nämlich dass Sie eingeschränkten Polymorphismus erhalten könnten, indem Sie Funktionsliterale in der API übergeben. Und diese spezifische Methode, die Sie vorgeschlagen haben, um den Mangel an eingeschränktem Polymorphismus zu umgehen, würde die Implementierung der alten API mehr oder weniger erfordern. dh Sie zitieren meine Antwort auf dieses Argument, das Sie dann nur wiederholen:

Wir würden die Leistungseinbußen gemäß dem Vorschlag, den wir diskutieren, ausgleichen, indem wir einfach die Definition in func Slice(slice []a, less func(a, a) bool) ändern.

Das ist aber die alte API. Sie sagen: "Mein Vorschlag erlaubt keinen eingeschränkten Polymorphismus, aber das ist kein Problem, da wir einfach keine Generika verwenden können und stattdessen die vorhandenen Lösungen (Reflektion/Schnittstellen) verwenden". Nun, auf „Ihr Vorschlag lässt die grundlegendsten Anwendungsfälle, für die die Leute Generika wollen, nicht zu“ mit „Wir können einfach die Dinge tun, die die Leute ohne Generika für diese grundlegendsten Anwendungsfälle tun“ zu antworten, scheint uns nicht zu verstehen überall, TBH. Ein Generika-Vorschlag, der Ihnen nicht einmal hilft, grundlegende Containertypen zu schreiben, Sort, Max ... scheint es einfach nicht wert zu sein.

Dies gilt für alle Vorschläge, die ich hier gesehen habe (einschließlich meiner eigenen).

Die meisten Generika-Vorschläge enthalten eine Möglichkeit, Typparameter einzuschränken. dh um auszudrücken "der Typparameter muss eine Less-Methode haben" oder "der Typparameter muss vergleichbar sein". Ihre – AFAICT – nicht.

Betrachten Sie die folgende Hash-Tabellendefinition:

Ihre Definition ist unvollständig. a) Der Schlüsseltyp muss auch gleich sein und b) Sie verhindern nicht, dass Sie unterschiedliche Schlüsseltypen verwenden. dh das wäre legal:

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)

Es sollte jedoch nicht legal sein, da Sie verschiedene Schlüsseltypen verwenden. dh der Container ist nicht im gewünschten Umfang typgeprüft. Sie müssen die Hashtabelle sowohl über den Schlüssel- als auch über den Werttyp parametrisieren

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

Oder, wenn es hilft, stellen Sie sich vor, Sie versuchen, ein Hash-Set zu implementieren. Sie würden das gleiche Problem bekommen, aber jetzt hat der resultierende Container keine zusätzliche Typprüfung über interface{} .

Aus diesem Grund geht Ihr Vorschlag nicht auf die grundlegendsten Anwendungsfälle ein: Er stützt sich auf Schnittstellen, um den Polymorphismus einzuschränken, bietet dann aber keine Möglichkeit, diese Schnittstellen auf Konsistenz zu überprüfen. Sie können entweder eine konsistente Typprüfung oder einen eingeschränkten Polymorphismus haben, aber nicht beides. Aber man braucht beides.

dass wir für eine erfolgreiche Generika-Implementierung in Go unbedingt etwas wie das Folgende haben müssen?

So denke ich zumindest, ja, ziemlich. Wenn ein Vorschlag es nicht erlaubt, typsichere Container zu schreiben oder zu sortieren oder …, fügt er der bestehenden Sprache nicht wirklich etwas hinzu, das signifikant genug ist, um die Kosten zu rechtfertigen.

@ Merovius Okay. Ich glaube, ich verstehe, was Sie wollen. Denken Sie daran, dass Ihre Anwendungsfälle sehr weit von dem entfernt sind, was ich möchte. Ich jucke nicht wirklich nach typsicheren Containern, obwohl ich vermute, dass dies - wie Sie sagten - eine Minderheitsmeinung sein könnte. Einige der größten Dinge, die ich sehen möchte, sind Ergebnistypen anstelle von Fehlern und eine einfache Slice-Manipulation ohne Duplizierung oder Reflexion überall, die mein Vorschlag angemessen angeht. Ich kann jedoch sehen, dass es aus Ihrer Sicht "nicht die grundlegendsten Anwendungsfälle anspricht", wenn Ihr grundlegender Anwendungsfall darin besteht, generische Container ohne die Verwendung von Schnittstellen zu schreiben.

Beachten Sie, dass diese Schnittstelle in Ihrem Vorschlag für Generika immer noch nicht möglich ist, da sie auf Reflektion für Länge und Austausch angewiesen ist (also haben Sie auch hier eine Einschränkung für Slice-Operationen). Selbst wenn wir diese API als die untere Grenze dessen akzeptieren, was Generika leisten können sollten (viele Leute würden das nicht tun. Es gibt immer noch viele Beschwerden über die mangelnde Typsicherheit in dieser API), würde Ihr Vorschlag nicht durchkommen diese Stange.

Wenn Sie dies lesen, ist klar, dass Sie die Art und Weise, wie die generischen Slices unter diesem Vorschlag funktionieren würden/sollten, gründlich missverstanden haben. Durch dieses Missverständnis sind Sie zu dem falschen Schluss gekommen, dass „diese Schnittstelle in Ihrem Vorschlag immer noch nicht möglich ist“. Unter jedem Vorschlag muss ein generisches Slice möglich sein, das ist meine Meinung. Und len() in der Welt, wie ich es gesehen habe, würde definiert werden als: func len(slice []a) , was ein generisches Slice-Argument ist, was bedeutet, dass es die Länge für jedes Slice auf nicht reflektierende Weise zählen kann. Dies ist der Hauptpunkt dieses Vorschlags, wie ich oben sagte (einfache Slice-Manipulation), und es tut mir leid, dass ich dies durch die von mir gegebenen Beispiele und den von mir gemachten Kern nicht so gut vermitteln konnte. Ein generisches Slice sollte genauso einfach verwendet werden können wie ein []int heute, ich sage noch einmal, dass jeder Vorschlag, der dies nicht anspricht (Slice/Array-Swaps, Zuweisung, Len, Cap usw. ) greift meiner Meinung nach zu kurz.

Alles in allem sind wir uns jetzt wirklich darüber im Klaren, was die Ziele des anderen sind. Als ich vorschlug, was ich tat, sagte ich sehr deutlich, dass es sich lediglich um einen syntaktischen Vorschlag handele und dass die Details sehr unscharf seien. Aber wir sind sowieso in die Details gegangen und eines dieser Details war das Fehlen von Einschränkungen. Als ich es schrieb, hatte ich sie einfach nicht im Sinn, weil sie für das, was ich gerne tun würde, nicht wichtig sind , heißt das nicht, dass wir sie nicht hinzufügen könnten oder dass sie nicht wünschenswert sind. Das Hauptproblem bei der Fortführung der vorgeschlagenen Syntax und dem Versuch, Einschränkungen einzubauen, wäre, dass sich die Definition eines generischen Arguments derzeit (absichtlich) wiederholt, sodass nicht auf Code an anderer Stelle verwiesen wird, um Einschränkungen usw. zu bestimmen. Wenn wir Einschränkungen einführen würden I sehe nicht, wie wir das halten könnten.

Das beste Gegenbeispiel ist die zuvor besprochene Sortierfunktion.

type Sort(slice []a:Lesser, less func(a:Lesser, a:Lesser)) { ... }

Wie Sie sehen können, gibt es keinen netten Weg, dies zu erreichen, und die Token-Spam-Ansätze für Generika klingen wieder besser. Um Einschränkungen für diese zu definieren, müssen wir zwei Dinge gegenüber dem ursprünglichen Vorschlag ändern:

• Es muss eine Möglichkeit geben, auf ein Typargument zu zeigen und ihm Einschränkungen zu geben.
• Die Einschränkungen müssen länger als eine einzelne Definition dauern, vielleicht ist dieser Bereich ein Typ, vielleicht ist dieser Bereich eine Datei (Datei klingt eigentlich ziemlich vernünftig).

Haftungsausschluss: Das Folgende ist keine tatsächliche Änderung des Vorschlags, da ich nur zufällige Symbole da draußen werfe. Ich verwende diese Syntaxen nur als Beispiele, um zu veranschaulichen, was wir tun könnten, um den Vorschlag in seiner ursprünglichen Form zu ändern

// 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

Beachten Sie noch einmal, dass ich dem Vorschlag nichts von dem oben Gesagten wirklich hinzufügen möchte. Ich zeige nur, welche Art von Konstrukten wir verwenden könnten, um das Problem zu lösen, und wie sie aussehen, ist im Moment etwas irrelevant.

Die Frage, die wir dann beantworten müssen, lautet: Gewinnen wir immer noch Wert aus den impliziten generischen Argumenten? Der Hauptpunkt des Vorschlags war, das saubere Go-ähnliche Gefühl der Sprache beizubehalten, die Dinge einfach zu halten, die Dinge ausreichend leise zu halten, indem übermäßige Token eliminiert wurden. In den vielen Fällen, in denen keine Einschränkungen erforderlich sind, z. B. eine Kartenfunktion oder die Definition eines Ergebnistyps, sieht es gut aus, fühlt es sich wie Go an, ist es nützlich? Vorausgesetzt, es gibt auch Constraints in irgendeiner Form.

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 Ich werde versuchen, es zu erklären. Der Grund, warum Sie Typbeschränkungen benötigen, ist, dass Sie nur so Funktionen oder Methoden für einen Typ aufrufen können. Betrachten Sie den uneingeschränkten Typ a , welcher Typ kann das sein, nun, es könnte ein String oder ein Int oder irgendetwas sein. Wir können also keine Funktionen oder Methoden darauf aufrufen, da wir den Typ nicht kennen. Wir könnten einen Typschalter und eine Laufzeitreflektion verwenden, um den Typ abzurufen, und dann einige Funktionen oder Methoden darauf aufrufen, aber das möchten wir mit Generika vermeiden. Wenn Sie einen Typ einschränken, zum Beispiel ist a ein Tier, können wir dann jede für ein Tier definierte Methode auf a aufrufen.

In Ihrem Beispiel können Sie zwar eine Mapper-Funktion übergeben, aber dies führt dazu, dass Funktionen viele Argumente annehmen, und ist im Grunde wie eine Sprache ohne Schnittstellen, nur erstklassige Funktionen. Um jede Funktion, die Sie verwenden werden, auf Typ a zu übergeben, wird in jedem echten Programm eine sehr lange Liste von Funktionen erstellt, insbesondere wenn Sie hauptsächlich generischen Code für die Abhängigkeitsinjektion schreiben, was Sie tun möchten Kopplung minimieren.

Was ist zum Beispiel, wenn die Funktion, die map aufruft, auch generisch ist? Was ist, wenn die Funktion, die das aufruft, generisch ist usw. Wie definieren wir Mapper, wenn wir den Typ von a noch nicht kennen?

func m(slice []a) []b {
   mapper := func(x a) b {...}
   return map(slice, mapper)
}

Welche Funktionen können wir für x aufrufen, wenn wir versuchen, mapper zu definieren?

@keean Ich verstehe den Zweck und die Funktion der Einschränkungen. Ich schätze sie einfach nicht so hoch wie einfache Dinge wie generische Containerstrukturen (sozusagen keine generischen Container) und generische Slices und habe sie daher nicht einmal in den ursprünglichen Vorschlag aufgenommen.

Ich glaube immer noch größtenteils, dass Schnittstellen die richtige Antwort auf Probleme wie das sind, von dem Sie sprechen, wo Sie Abhängigkeitsinjektion durchführen, das scheint einfach nicht der richtige Ort für Generika zu sein, aber wer soll ich sagen. Die Überschneidung zwischen ihren Verantwortlichkeiten ist in meinen Augen ziemlich groß, daher mussten @Merovius und ich die Diskussion führen, ob wir ohne sie leben könnten oder nicht, und er hat mich ziemlich davon überzeugt, dass sie in einigen Anwendungsfällen nützlich sein würden, daher ich ein wenig untersucht, was wir tun könnten, um die Funktion zu dem Vorschlag hinzuzufügen, den ich ursprünglich gemacht habe.

In Ihrem Beispiel können Sie keine Funktionen auf x aufrufen. Sie können das Slice jedoch wie jedes andere Slice bearbeiten, was für sich genommen enorm nützlich ist. Ich bin mir auch nicht sicher, was die Funktion in der Funktion ist ... vielleicht wollten Sie eine Variable zuweisen?

@aarondl
Danke, ich habe die Syntax korrigiert, aber ich denke, die Bedeutung war immer noch klar.

In den Beispielen, die ich oben gegeben habe, wurden sowohl parametrischer Polymorphismus als auch Schnittstellen verwendet, um ein gewisses Maß an generischer Programmierung zu erreichen. Das Fehlen von Mehrfachversand wird jedoch immer eine Obergrenze für das erreichbare Maß an Allgemeingültigkeit setzen. Als solches scheint Go nicht die Funktionen zu bieten, die ich in einer Sprache suche, das bedeutet nicht, dass ich Go nicht für einige Aufgaben verwenden kann, und tatsächlich bin ich es bereits und es funktioniert gut, auch wenn ich es getan habe zum Ausschneiden und Einfügen von Code, der wirklich nur eine Definition benötigt. Ich hoffe nur, dass der Entwickler in Zukunft alle eingefügten Instanzen finden kann, wenn dieser Code geändert werden muss.

Ich bin mir dann nicht sicher, ob die begrenzte Allgemeingültigkeit, die ohne solch große Änderungen an der Sprache möglich ist, eine gute Idee ist, wenn man bedenkt, wie kompliziert sie sein wird. Vielleicht ist Go besser einfach, und die Leute können Makros wie die Vorverarbeitung oder andere Sprachen hinzufügen, die zu Go kompiliert werden, um diese Funktionen bereitzustellen? Andererseits wäre das Hinzufügen von parametrischem Polymorphismus ein guter erster Schritt. Es wäre ein guter nächster Schritt, zuzulassen, dass diese Typparameter eingeschränkt werden. Dann könnten Sie Schnittstellen zugeordnete Typparameter hinzufügen, und Sie hätten etwas einigermaßen Generisches, aber das ist wahrscheinlich alles, was Sie ohne Mehrfachdispatch erreichen können. Durch die Aufteilung in separate kleinere Funktionen würden Sie die Chance erhöhen, dass sie akzeptiert werden?

@Keean
Ist Mehrfachversand alles nötig? Nur sehr wenige Sprachen unterstützen es nativ. Selbst C++ unterstützt es nicht. C# unterstützt es irgendwie über dynamic , aber ich habe es nie in der Praxis verwendet und das Schlüsselwort im Allgemeinen ist in echtem Code sehr, sehr selten. Beispiele, an die ich mich erinnere, befassen sich mit etwas wie JSON-Parsing und nicht mit dem Schreiben von Generika.

Ist Mehrfachversand alles nötig?

IMHO, ich denke, @keean spricht über statischen Mehrfachversand, der von Typklassen/Schnittstellen bereitgestellt wird.
Dies wird sogar in C++ durch Methodenüberladung bereitgestellt (ich weiß es nicht für C#)

Was Sie meinen, ist der dynamische Mehrfachversand, der in statischen Sprachen ohne Union-Typen ziemlich umständlich ist. Dynamische Sprachen umgehen dieses Problem, indem sie die statische Typprüfung weglassen (partieller Typrückschluss für dynamische Sprachen, dasselbe für den „dynamischen“ Typ von C#).

Könnte ein Typ "nur" als Parameter bereitgestellt werden?

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 schrieb:

Könnte ein Typ "nur" als Parameter bereitgestellt werden?

Fraglich, inwieweit dies in go möglich oder erwünscht wäre

Was Sie wollen, könnte stattdessen erreicht werden, wenn generische Einschränkungen unterstützt werden:

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)

Auch dies sollte mit Einschränkungen möglich sein:

func convert(value s) t requires Convertible<s,t>{
    return t(value);
}

f:float64:=2.0

i:int64=convert(f)

Für das, was es wert ist, unterstützt unsere Genus-Sprache den Mehrfachversand. Modelle für eine Einschränkung können mehrere Implementierungen bereitstellen, an die gesendet wird.

Ich verstehe, dass die Notation Convertible<s,t> für die Kompilierzeitsicherheit benötigt wird, aber möglicherweise zu einer Laufzeitprüfung degradiert werden könnte

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)

Aber das sieht eher nach Syntaxzucker für reflect aus.

@Inuart Der Punkt ist, dass der Compiler überprüfen kann, ob der Typ die Typklasse zur Kompilierzeit implementiert, sodass die Laufzeitprüfung nicht erforderlich ist. Der Vorteil ist eine bessere Leistung (sogenannte Nullkosten-Abstraktion). Wenn es sich um eine Laufzeitprüfung handelt, können Sie auch reflect verwenden.

@kreker

Ist Mehrfachversand alles nötig?

Ich mache mir zu viele Gedanken darüber. Einerseits funktioniert Multiple-Dispatch (mit Klassen vom Typ Multi-Parameter) nicht gut mit Existentials, was 'Go' 'Schnittstellenwerte' nennt.

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}}
}

Wir können den Abschnitt von Equals nicht definieren, da wir keine Möglichkeit haben, anzugeben, dass der rechte Parameter aus derselben Sammlung stammt. Wir können dies nicht einmal in Haskell tun:

data Equals = forall a . IEquals a a => Equals a

Das ist nicht gut, weil es nur erlaubt, einen Typ mit sich selbst zu vergleichen

data Equals = forall a b . IEquals a b => Equals a

Das ist nicht gut, weil wir keine Möglichkeit haben, b darauf zu beschränken, ein weiteres Existential in derselben Sammlung wie a zu sein (wenn a überhaupt in einer Sammlung ist).

Es macht es jedoch sehr einfach, mit einem neuen Typ zu erweitern:

(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}

Und das wäre noch prägnanter mit Standardinstanzen oder Spezialisierungen.

Andererseits können wir dies in 'Go' umschreiben, das jetzt funktioniert:

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]))
}

Dies funktioniert gut mit dem existenziellen Wert (Schnittstellenwert), ist jedoch viel komplexer, schwerer zu erkennen, was vor sich geht und wie es funktioniert, und es hat die große Einschränkung, dass wir eine Schnittstelle pro Typ benötigen und das Akzeptable fest codieren müssen Typen auf der rechten Seite wie folgt:

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

Das bedeutet, dass wir die Bibliotheksquelle ändern müssten, um einen neuen Typ hinzuzufügen, da die Schnittstelle EqualsRight nicht erweiterbar ist.

Ohne Schnittstellen mit mehreren Parametern können wir also keine erweiterbaren generischen Operatoren wie Gleichheit definieren. Bei Multiparameter-Schnittstellen werden Existentiale (Schnittstellenwerte) problematisch.

Mein Hauptproblem bei vielen der vorgeschlagenen Syntaxen (Syntaxen?) Blah[E] ist, dass der zugrunde liegende Typ keine Informationen über enthaltende Generika anzeigt.

Zum Beispiel:

type Comparer[C] interface {
    Compare(other C) bool
}
// or
type Comparer c interface {
    Compare(other c) bool
}
...

Dies bedeutet, dass wir einen neuen Typ deklarieren, der dem zugrunde liegenden Typ weitere Informationen hinzufügt. Ist es nicht der Sinn der type -Deklaration, einen Namen basierend auf einem anderen Typ zu definieren?

Ich würde eine Syntax eher in Richtung von vorschlagen

type Comparer interface[C] {
    Compare(other C) bool
}

Das bedeutet, dass Comparer eigentlich nur ein Typ ist, der auf interface[C] { ... } basiert, und interface[C] { ... } natürlich ein eigener Typ von interface { ... } ist. Dadurch können Sie eine generische Schnittstelle verwenden, ohne sie zu benennen, wenn Sie möchten (was bei normalen Schnittstellen zulässig ist). Ich denke, diese Lösung ist etwas intuitiver und funktioniert gut mit dem Typsystem von Go, obwohl ich mich bitte korrigieren sollte, wenn ich falsch liege.

Hinweis: Das Deklarieren eines generischen Typs wäre nur für Schnittstellen, Strukturen und Funktionen mit den folgenden Syntaxen zulässig:
interface[G] { ... }
struct[G] { ... }
func[G] (vars...) { ... }

Dann hätte die "Implementierung" der Generika die folgenden Syntaxen:
interface[G] { ... }[string]
struct[G] { ... }[string]
func[G] (vars...) { ... }[int](args...)

Und mit einigen Beispielen, um es etwas klarer zu machen:

Schnittstellen

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)
}

Strukturen

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)
}

Funktionen

func[A] AddManyTo(a Adder[A], many ...A) {
    for _, each := range a {
        a.Add(each)
    }
}

Dies ist eine Reaktion auf den Go2-Vertragsentwurf und ich werde seine Syntax verwenden, aber ich poste sie hier, da sie für jeden Vorschlag für parametrischen Polymorphismus gilt.

Das Einbetten von Typparametern sollte nicht erlaubt sein.

Erwägen

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.

für einen beliebigen Typ R und einen beliebigen Vertrag C , der Foo() nicht enthält.

T hat alle Selektoren, die von C benötigt werden, aber eine bestimmte Instanziierung von T kann auch beliebige andere Selektoren haben, einschließlich Foo .

Nehmen wir an, Bar ist eine Struktur, zulässig unter C , die ein Feld namens Foo hat.

X(Bar) könnte eine illegale Instantiierung sein. Ohne eine Möglichkeit, den Vertrag anzugeben, dass ein Typ keinen Selektor hat, müsste dies eine abgeleitete Eigenschaft sein.

Methoden von X(Bar) könnten Verweise auf Foo weiterhin als X(Bar).R.Foo auflösen. Dies ermöglicht das Schreiben des generischen Typs, könnte jedoch für einen Leser, der mit der Spitzfindigkeit der Auflösungsregeln nicht vertraut ist, verwirrend sein. Außerhalb der Methoden von X würde der Selektor mehrdeutig bleiben, während interface { Foo() } nicht von den Parametern von X abhängt, einige Instanziierungen von X würden dies tun nicht befriedigen.

Das Verbieten der Einbettung eines Typparameters ist einfacher.

(Wenn dies jedoch zulässig sein soll, wäre der Feldname T aus demselben Grund, aus dem der Feldname eines eingebetteten S , das als type S = io.Reader definiert ist, S ist Reader , sondern auch, weil der Typ, der T instanziiert, nicht unbedingt einen Namen haben muss.)

@jimmyfrasche Ich denke, dass eingebettete Felder mit generischen Typen nützlich genug sind, dass es gut wäre, sie zuzulassen, auch wenn es an einigen Stellen etwas unangenehm sein könnte. Mein Vorschlag wäre, im gesamten generischen Code anzunehmen, dass der eingebettete Typ alle möglichen Felder und Methoden auf jeder möglichen Ebene definiert hat , sodass im generischen Code alle eingebetteten Methoden und Felder nicht generischer Typen gelöscht werden.

Also gegeben:

type R struct(type T) {
    io.Reader
    T
}

Methoden auf R wären nicht in der Lage, Read auf R aufzurufen, ohne über Reader umzuleiten. Beispielsweise:

func (r R) Do() {
     r.Read(buf)     // Illegal
     r.Reader.Read(buf)  // ok
}

Der einzige Nachteil, den ich sehen kann, ist, dass der dynamische Typ möglicherweise mehr Mitglieder enthält als der statische Typ. Beispielsweise:

func (r R) Do() {
    var x interface{} = r
    x.(io.Reader)    // Succeeds
}

@rogpeppe

Der einzige Nachteil, den ich sehen kann, ist, dass der dynamische Typ möglicherweise mehr Mitglieder enthält als der statische Typ.

Dies ist bei Typparametern direkt der Fall, daher sollte es meiner Meinung nach auch bei parametrischen Typen in Ordnung sein. Ich denke, die Lösung für das von @jimmyfrasche vorgestellte Problem könnte darin bestehen, den gewünschten Methodensatz des parametrisierten Typs in den Vertrag aufzunehmen.

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.

Dadurch könnte Foo direkt auf X aufgerufen werden. Das würde natürlich gegen die Regel "keine lokalen Namen in Verträgen" verstoßen ...

@stevenblenkinsop Hmm , es ist möglich, wenn es umständlich ist, dies zu tun, ohne sich auf X zu beziehen

contract C(t T) {
  struct{ R; T }{}.Foo
}

C ist immer noch an die Implementierung von X gebunden, wenn auch etwas lockerer.

Wenn Sie das nicht tun, und Sie schreiben

func (x X(T)) Fooer() interface { Foo() } {
  return x
}

kompiliert es? Es würde nicht unter die Regel von @rogpeppe fallen , die anscheinend auch übernommen werden müsste, wenn Sie die Garantie im Vertrag nicht übernehmen. Aber gilt es dann nur, wenn Sie ein Typargument ohne ausreichenden Vertrag einbetten oder für alle Einbettungen?

Es wäre einfacher, es einfach zu verbieten.

Ich habe mit der Arbeit an diesem Vorschlag begonnen, bevor der Go2-Entwurf angekündigt wurde.

Als ich die Ankündigung sah, war ich bereit, meinen zu verschrotten, aber ich bin immer noch verunsichert wegen der Komplexität des Entwurfs, also habe ich meinen fertiggestellt. Es ist weniger leistungsfähig, aber einfacher. Wenn nichts anderes, kann es einige Bits geben, die es wert sind, gestohlen zu werden.

Es erweitert die Syntax der früheren Vorschläge von @ianlancetaylor , da diese verfügbar war, als ich anfing. Das ist nicht grundlegend. Es könnte durch eine (type T etc. Syntax oder etwas Äquivalentes ersetzt werden. Ich brauchte nur etwas Syntax als Notation für die Semantik.

Es befindet sich hier: https://gist.github.com/jimmyfrasche/656f3f47f2496e6b49e041cd8ac716e4

Die Regel müsste lauten, dass jede Methode, die aus einer größeren Tiefe als der eines eingebetteten Typparameters heraufgestuft wird, nicht aufgerufen werden kann, es sei denn, (1) die Identität des Typarguments ist bekannt oder (2) die Methode wird als aufrufbar nach außen bestätigt Typ durch den Vertrag, der den Typparameter einschränkt. Der Compiler könnte auch Ober- und Untergrenzen für die Tiefe bestimmen, die eine hochgestufte Methode innerhalb des äußeren Typs O haben muss, und sie verwenden, um zu bestimmen, ob die Methode für einen Typ aufrufbar ist, der O einbettet. dh ob ein Konfliktpotential mit anderen geförderten Methoden besteht oder nicht. Etwas Ähnliches würde auch für alle Typparameter gelten, von denen behauptet wird, dass sie über aufrufbare Methoden verfügen, wobei die Tiefenbereiche der Methoden innerhalb des Typparameters [0, inf] wären.

Das Einbetten von Typparametern scheint einfach zu nützlich, um es vollständig zu verbieten. Zum einen ermöglicht es eine transparente Komposition, die das Muster der Einbettung von Schnittstellen nicht zulässt.

Ich fand auch eine potenzielle Verwendung bei der Definition von Verträgen. Wenn Sie in der Lage sein möchten, einen Wert vom Typ T (der ein Zeigertyp sein könnte) zu akzeptieren, für den möglicherweise Methoden auf *T definiert sind, und Sie diesen Wert einfügen können möchten eine Schnittstelle, können Sie nicht unbedingt T in die Schnittstelle einfügen, da die Methoden möglicherweise auf *T , und Sie können nicht unbedingt *T in die Schnittstelle einfügen, weil T könnte selbst ein Zeigertyp sein (und daher könnte *T einen leeren Methodensatz haben). Wenn Sie jedoch eine Verpackung mögen

type Wrapper(type T) { T }

Sie könnten in jedem Fall *Wrapper(T) in die Schnittstelle einfügen, wenn Ihr Vertrag besagt, dass er die Schnittstelle erfüllt.

Kannst du nicht einfach tun

type Interface interface {
  SomeMethod(int) error
}

contract MightBeAPointer(t T) {
  Interface(t)
}

func Example(type T MightBeAPointer)(v T) {
  var i Interface = v
  // ...
}

Ich versuche, den Fall zu behandeln, wo jemand anruft

type S struct{}
func (s *S) SomeMethod(int) error { ... }
...
var s S
Example(S)(s)

Dies funktioniert nicht, da S nicht in Interface konvertiert werden kann, sondern nur *S .

Offensichtlich könnte die Antwort "Tu das nicht" lauten. Der Vertragsvorschlag beschreibt jedoch Verträge wie:

contract Contract(t T) {
    var _ error = t.SomeMethod(int(0))
}

S würde diesen Vertrag aufgrund der automatischen Adressierung erfüllen, ebenso wie *S . Was ich anzugehen versuche, ist die Fähigkeitslücke zwischen Methodenaufrufen und Schnittstellenkonvertierungen in Verträgen.

Wie auch immer, dies ist ein bisschen eine Tangente, die eine mögliche Verwendung für das Einbetten von Typparametern zeigt.

Beim Einbetten denke ich, dass „kann in eine Struktur eingebettet werden“ eine weitere Einschränkung ist, die die Verträge erfassen müssten, wenn dies zulässig wäre.

Erwägen:

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)

Das Einbetten von @bcmills- Typen mit mehrdeutigen Selektoren ist zulässig, daher bin ich mir nicht sicher, wie dieser Vertrag interpretiert werden soll.

Auf jeden Fall ist es in Ordnung, wenn Sie nur bekannte Typen einbetten. Wenn Sie nur Typparameter einbetten, ist das in Ordnung. Der einzige Fall, der seltsam wird, ist, wenn Sie einen oder mehrere bekannte Typen UND einen oder mehrere Typparameter einbetten, und dann nur, wenn die Selektoren der bekannten Typen und die Typargumente nicht disjunkt sind

Das Einbetten von @bcmills- Typen mit mehrdeutigen Selektoren ist zulässig, daher bin ich mir nicht sicher, wie dieser Vertrag interpretiert werden soll.

Hm, guter Punkt. Mir fehlt eine weitere Einschränkung, um den Fehler auszulösen.¹

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
    var _ io.Reader = S{}
}

¹ https://play.golang.org/p/3wSg5aRjcQc

Dazu muss einer von X oder Y aber nicht beide ein io.Reader sein. Es ist interessant, dass das Vertragssystem ausdrucksstark genug ist, um dies zuzulassen. Ich bin froh, dass ich nicht die Typschlussregeln für solch ein Biest herausfinden muss.

Aber das ist nicht wirklich das Problem.

Es ist, wenn Sie es tun

type S (type T C) struct {
  io.Reader
  T
}
func (s *S(T)) X() io.Reader {
  return s
}

Das sollte nicht kompiliert werden, da T einen Read -Selektor haben könnte, es sei denn, C hat einen

struct{ io.Reader; T }.Read

Aber was sind dann die Regeln, wenn C nicht sicherstellt, dass die Selektorsätze disjunkt sind und S nicht auf die Selektoren verweist? Ist es möglich, dass jede Instanziierung S eine Schnittstelle erfüllt, mit Ausnahme von Typen, die einen mehrdeutigen Selektor erstellen?

Ist es möglich, dass jede Instanziierung S eine Schnittstelle erfüllt, mit Ausnahme von Typen, die einen mehrdeutigen Selektor erstellen?

Ja, das scheint so zu sein. Ich frage mich, ob das etwas Tieferes impliziert... 🤔

Ich konnte nichts unwiderruflich Böses konstruieren, aber die Asymmetrie ist ziemlich unangenehm und macht mich unruhig:

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

Ich mache mir Sorgen über die Fehlermeldungen, wenn G0(B) ein G1(B) verwendet ein . . . verwendet ein Gn(B) und Gn ist derjenige, der den Fehler verursacht. . . .

FTR, Sie müssen sich nicht mit mehrdeutigen Selektoren herumschlagen, um Typfehler beim Einbetten auszulösen.

// Error: Duplicate field name Reader
type Boom = Embedded(*bytes.Reader, *strings.Reader)

Sie gehen davon aus, dass der eingebettete Feldname auf dem Argumenttyp basiert, während es sich eher um den Namen des eingebetteten Typparameters handelt. Dies ist so, als ob Sie einen Typalias einbetten und der Feldname der Alias ​​ist und nicht der Name des Typs, den er aliasiert.

Dies ist tatsächlich im Entwurf im Abschnitt über parametrisierte Typen angegeben :

Wenn ein parametrisierter Typ eine Struktur ist und der Typparameter als Feld in die Struktur eingebettet ist, ist der Name des Felds der Name des Typparameters, nicht der Name des Typarguments.

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
}

(Hinweis: Dies funktioniert schlecht, wenn Sie Lockable(X) in die Methodendeklaration schreiben: Soll die Methode lT oder lX zurückgeben? Vielleicht sollten wir einfach das Einbetten eines Typparameters in eine Struktur verbieten.)

Ich sitze nur hier hinten an der Seitenlinie und beobachte. Aber mache mir auch ein bisschen Sorgen.

Ich schäme mich nicht zu sagen, dass 90 % dieser Diskussion über meinen Kopf geht.

Es scheint, dass 20 Jahre, in denen ich meinen Lebensunterhalt mit dem Schreiben von Software verdient habe, ohne zu wissen, was Generika oder parametrischer Polymorphismus sind, mich nicht davon abgehalten haben, die Arbeit zu erledigen.

Leider habe ich mir erst vor etwa einem Jahr die Zeit genommen, Go zu lernen. Ich ging fälschlicherweise davon aus, dass es eine steile Lernkurve sei und es zu lange dauern würde, bis ich produktiv werde.

Ich hätte nicht falscher liegen können.

Ich konnte genug Go lernen, um einen Microservice zu erstellen, der den node.js-Dienst, mit dem ich Leistungsprobleme hatte, in weniger als einem Wochenende vollständig zerstörte.

Ironischerweise habe ich nur herumgespielt. Es war mir nicht besonders ernst damit, mit Go die Welt zu erobern.

Und doch stellte ich fest, dass ich mich innerhalb weniger Stunden aus meiner zusammengesunkenen, besiegten Haltung aufsetzte, als ob ich auf der Kante meines Sitzes sitzen würde und einen Action-Thriller ansehen würde. Die API, die ich erstellte, kam so schnell zusammen. Mir wurde klar, dass es sich tatsächlich lohnt, in diese Sprache meine kostbare Zeit zu investieren, weil sie offensichtlich so pragmatisch in ihrem Design war.

Und das liebe ich an Go. Es ist sehr schnell..... Zu lernen. Wir alle hier kennen seine Leistungsfähigkeit. Aber die Geschwindigkeit, mit der es gelernt werden kann, ist unübertroffen von den 8 anderen Sprachen, die ich im Laufe der Jahre gelernt habe.

Seitdem singe ich Gos Loblieder und habe 4 weitere Entwickler dazu gebracht, sich in es zu verlieben. Ich sitze einfach ein paar Stunden mit ihnen zusammen und baue etwas. Ergebnisse sprechen für sich.

Einfachheit und Schnelligkeit des Lernens. Dies sind die wahren Killer-Features der Sprache.

Programmiersprachen, die monatelanges hartes Lernen erfordern, halten oft nicht genau die Entwickler, die sie anziehen wollen. Wir haben Arbeit zu erledigen und Arbeitgeber, die täglich Fortschritte sehen wollen (danke agile, weiß es zu schätzen)

Ich hoffe also, dass das Go-Team zwei Dinge berücksichtigen kann:

1) Welches alltägliche Problem wollen wir lösen?

Ich kann anscheinend kein Beispiel aus der realen Welt finden, mit einem Showstopper, der durch Generika oder wie auch immer sie heißen werden, gelöst werden würde.

Kochbuchartige Beispiele für alltägliche Aufgaben, die problematisch sind, mit einem Beispiel dafür, wie sie mit diesen Sprachänderungsvorschlägen verbessert werden könnten.

2) Halten Sie es einfach, wie alle anderen großartigen Funktionen von Go

Es gibt einige unglaublich intelligente Kommentare hier. Aber ich bin mir sicher, dass die Mehrheit der Entwickler, die Go täglich für die allgemeine Programmierung verwenden, wie ich selbst, mit den Dingen, wie sie sind, vollkommen zufrieden und produktiv sind.

Vielleicht ein Compiler-Argument, um solche erweiterten Funktionen zu aktivieren? '--hardcore'

Ich wäre wirklich traurig, wenn wir die Compilerleistung negativ beeinflussen würden. Sag's einfach

Und das liebe ich an Go. Es ist sehr schnell..... Zu lernen. Wir alle hier kennen seine Leistungsfähigkeit. Aber die Geschwindigkeit, mit der es gelernt werden kann, ist unübertroffen von den 8 anderen Sprachen, die ich im Laufe der Jahre gelernt habe.

Ich stimme vollkommen zu. Die Kombination von Leistung und Einfachheit in einer vollständig kompilierten Sprache ist etwas völlig Einzigartiges. Ich möchte definitiv nicht, dass Go das verliert, und so sehr ich Generika will, glaube ich nicht, dass sie es auf diese Kosten wert sind. Ich glaube aber nicht, dass es notwendig ist, das zu verlieren.

Ich kann anscheinend kein Beispiel aus der realen Welt finden, mit einem Showstopper, der durch Generika oder wie auch immer sie heißen werden, gelöst werden würde.

Ich habe zwei hauptsächliche Anwendungsfälle für Generika: Typsichere Boilerplate-Eliminierung komplexer Datenstrukturen wie Binärbäume, Mengen und sync.Map und die Fähigkeit, typsichere Funktionen zur _Kompilierungszeit_ zu schreiben, die basierend arbeiten ausschließlich auf die Funktionalität ihrer Argumente und nicht auf ihr Layout im Speicher. Es gibt einige ausgefallenere Dinge, die ich gerne tun könnte, aber es würde mir nichts ausmachen, sie zu tun, wenn es unmöglich ist, Unterstützung für sie hinzuzufügen, ohne die Einfachheit der Sprache vollständig zu brechen.

Um ehrlich zu sein, gibt es bereits Funktionen in der Sprache, die ziemlich missbrauchbar sind. Der Hauptgrund dafür, dass sie _nicht_ so oft missbraucht werden, ist meiner Meinung nach die Go-Kultur des Schreibens von „idiomatischem“ Code, kombiniert mit der Standardbibliothek, die größtenteils saubere, leicht zu findende Beispiele für solchen Code bereitstellt. Eine gute Verwendung von Generika in der Standardbibliothek sollte definitiv eine Priorität sein, wenn sie implementiert werden.

@camstuart

Ich kann anscheinend kein Beispiel aus der realen Welt finden, mit einem Showstopper, der durch Generika oder wie auch immer sie heißen werden, gelöst werden würde.

Generics sind so, dass Sie den Code nicht selbst schreiben müssen. Sie müssen also nie wieder eine andere verknüpfte Liste, einen Binärbaum, eine Deque oder eine Priority-Queue selbst implementieren. Sie müssen niemals einen Sortieralgorithmus, einen Partitionierungsalgorithmus oder einen Rotationsalgorithmus usw. implementieren. Datenstrukturen werden zu komponierenden Standardsammlungen (z. und drehen). Wenn Sie diese Komponenten wiederverwenden können, sinkt die Fehlerrate, denn jedes Mal, wenn Sie eine Prioritätswarteschlange oder einen Partitionierungsalgorithmus neu implementieren, besteht die Möglichkeit, dass Sie etwas falsch machen und einen Fehler einführen.

Generics bedeutet, dass Sie weniger Code schreiben und mehr wiederverwenden. Sie bedeuten, dass gut gewartete Standardbibliotheksfunktionen und abstrakte Datentypen in mehr Situationen verwendet werden können, sodass Sie keine eigenen schreiben müssen.

Noch besser ist, dass all dies technisch bereits jetzt in Go möglich ist, aber nur mit einem nahezu vollständigen Verlust der Typsicherheit während der Kompilierzeit _und_ mit einem möglicherweise erheblichen Laufzeit-Overhead. Mit Generika können Sie dies ohne diese Nachteile tun.

Generische Funktionsimplementierung:

/*

* "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
}

Funktionsaufrufer:

Sum(1, 1) // 2
// same as:
Sum(T{int}(1), T{int}(1)) // 2

Generische Strukturimplementierung:

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)
}

Anrufer:

list := NewList(ItemT{int})
list.Push(42)

Als jemand, der gerade Swift lernt und es nicht mag, aber viel Erfahrung in anderen Sprachen wie Go, C, Java usw. hat; Ich glaube wirklich, dass Generics (oder Templating oder wie auch immer Sie es nennen wollen) keine gute Sache sind, um sie der Go-Sprache hinzuzufügen.

Vielleicht habe ich einfach mehr Erfahrung mit der aktuellen Version von Go, aber für mich fühlt sich das wie eine Regression zu C++ an, da es schwieriger ist, Code zu verstehen, den andere Leute geschrieben haben. Der klassische T-Platzhalter für Typen macht es so schwierig zu verstehen, was eine Funktion zu tun versucht.

Ich weiß, dass dies eine beliebte Feature-Anfrage ist, also kann ich damit umgehen, wenn sie landet, aber ich wollte meine 2 Cent (Meinung) hinzufügen.

@jlubawy
Kennen Sie eine andere Möglichkeit, dass ich niemals eine verknüpfte Liste oder einen Quicksort-Algorithmus implementieren muss? Wie Alexander Stepanov betont, können die meisten Programmierer die „min“- und „max“-Funktionen nicht korrekt definieren. Welche Hoffnung haben wir also, komplexere Algorithmen ohne viel Debugging-Zeit korrekt zu implementieren? Ich würde viel lieber Standardversionen dieser Algorithmen aus einer Bibliothek ziehen und sie einfach auf die Typen anwenden, die ich habe. Welche Alternative gibt es?

@jlubawy

oder Templating, oder wie auch immer Sie es nennen wollen

Alles hängt von der Umsetzung ab. Wenn wir über C++-Vorlagen sprechen, dann ja, sie sind im Allgemeinen schwer zu verstehen. Selbst das Schreiben ist schwierig. Wenn wir andererseits C#-Generika nehmen, dann ist das eine ganz andere Sache. Das Konzept an sich ist hier kein Problem.

Falls Sie es noch nicht wussten, das Go-Team hat einen Entwurf von Go 2.0 angekündigt:
https://golang.org/s/go2designs

Es gibt einen Entwurf zum Generics-Design in Go 2.0 (Vertrag). Vielleicht möchten Sie einen Blick auf ihr Wiki werfen und Feedback geben.

Dies ist der relevante Abschnitt:

Generika

• Überblick
• Entwurf
• Wiki-Feedback-Seite

Nachdem ich den Entwurf gelesen habe, frage ich:

Warum

T: Addierbar

bedeutet "ein Typ T, der den Vertrag Addable umsetzt"? Warum eine neue hinzufügen
Konzept, wenn wir dafür schon SCHNITTSTELLEN haben? Schnittstellenbelegung ist
in der Bauzeit eingecheckt, sodass wir bereits die Mittel haben, keine zu benötigen
zusätzliches Konzept hier. Wir können diesen Begriff verwenden, um so etwas zu sagen wie: Beliebig
Typ T, der die Schnittstelle Addable implementiert. Zusätzlich T:_ oder T:Any
(Any ist ein spezielles Schlüsselwort oder ein eingebauter Alias ​​von interface{}).
der Trick.

Ich weiß nur nicht, warum ich die meisten Sachen so neu implementieren soll. Macht nein
sinnvoll und WERDEN redundant sein (so redundant ist die neue Behandlung von Fehlern bzgl
Umgang mit Panik).

2018-09-14 6:15 GMT-05:00 Koala Yeung [email protected] :

Falls Sie es noch nicht wussten, das Go-Team hat einen Entwurf von Go 2.0 angekündigt:
https://golang.org/s/go2designs

Es gibt einen Entwurf zum Generics-Design in Go 2.0 (Vertrag). Du möchtest vielleicht
mal reinschauen und Feedback geben
https://github.com/golang/go/wiki/Go2GenericsFeedback zu ihrem Wiki
https://github.com/golang/go/wiki/Go2GenericsFeedback .

Dies ist der relevante Abschnitt:

Generika

• Überblick
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [Designentwurf] (https://go.googlesource.com/proposal/+/master/design/
  go2Entwürfe-Verträge.md)
• Wiki-Feedback-Seite
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment-421326634 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
Dies ist ein Test für E-Mail-Signaturen, die in TripleMint verwendet werden sollen

Bearbeiten: "[...] würde den Zweck erfüllen, WENN SIE KEINE BESTIMMTE ANFORDERUNG BRAUCHEN
DAS TYP-ARGUMENT".

17.09.2018 11:10 GMT-05:00 Luis Masuelli [email protected] :

Nachdem ich den Entwurf gelesen habe, frage ich:

Warum

T: Addierbar

bedeutet "ein Typ T, der den Vertrag Addable umsetzt"? Warum eine neue hinzufügen
Konzept, wenn wir dafür schon SCHNITTSTELLEN haben? Schnittstellenbelegung ist
in der Bauzeit eingecheckt, sodass wir bereits die Mittel haben, keine zu benötigen
zusätzliches Konzept hier. Wir können diesen Begriff verwenden, um so etwas zu sagen wie: Beliebig
Typ T, der die Schnittstelle Addable implementiert. Zusätzlich T:_ oder T:Any
(Any ist ein spezielles Schlüsselwort oder ein eingebauter Alias ​​von interface{}).
der Trick.

Ich weiß nur nicht, warum ich die meisten Sachen so neu implementieren soll. Macht nein
sinnvoll und WERDEN redundant sein (so redundant ist die neue Behandlung von Fehlern bzgl
Umgang mit Panik).

2018-09-14 6:15 GMT-05:00 Koala Yeung [email protected] :

Falls Sie es noch nicht wussten, das Go-Team hat einen Entwurf von Go 2.0 angekündigt:
https://golang.org/s/go2designs

Es gibt einen Entwurf zum Generics-Design in Go 2.0 (Vertrag). Sie können
möchte mal reinschauen und Feedback geben
https://github.com/golang/go/wiki/Go2GenericsFeedback zu ihrem Wiki
https://github.com/golang/go/wiki/Go2GenericsFeedback .

Dies ist der relevante Abschnitt:

Generika

• Überblick
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [Designentwurf] (https://go.googlesource.com/p
  roposal/+/master/design/go2draft-contracts.md
  https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
  )
• Wiki-Feedback-Seite
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
Sie erhalten dies, weil Sie kommentiert haben.
Antworten Sie direkt auf diese E-Mail und zeigen Sie sie auf GitHub an
https://github.com/golang/go/issues/15292#issuecomment-421326634 oder stumm
der Faden
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
Dies ist ein Test für E-Mail-Signaturen, die in TripleMint verwendet werden sollen

--
Dies ist ein Test für E-Mail-Signaturen, die in TripleMint verwendet werden sollen

@luismasuelli-jobsity Wenn ich die Geschichte der generischen Implementierungen in Go richtig gelesen habe, dann sieht es so aus, als ob der Grund für die Einführung von Contracts darin besteht, dass sie keine Operatorüberladung in Interfaces wollten.

Ein früherer Vorschlag, der schließlich abgelehnt wurde, verwendete Schnittstellen, um parametrischen Polymorphismus einzuschränken, scheint jedoch abgelehnt worden zu sein, weil Sie in solchen Funktionen keine allgemeinen Operatoren wie '+' verwenden konnten, da es in einer Schnittstelle nicht definierbar ist. Verträge ermöglichen es Ihnen, t == t oder t + t zu schreiben, damit Sie angeben können, dass der Typ Gleichheit oder Addition usw. unterstützen muss.

Bearbeiten: Auch Go unterstützt keine Schnittstellen mit mehreren Typparametern, also hat Go in gewisser Weise die Typklasse in zwei separate Dinge getrennt, Verträge, die die Funktionstypparameter miteinander in Beziehung setzen, und Schnittstellen, die Methoden bereitstellen. Was dabei verloren geht, ist die Möglichkeit, eine Typklassenimplementierung basierend auf mehreren Typen auszuwählen. Es ist wohl einfacher, wenn Sie nur Schnittstellen oder Verträge verwenden müssen, aber komplexer, wenn Sie beide zusammen verwenden müssen.

Warum bedeutet T:Addable "ein Typ T, der den Vertrag Addable implementiert"?

Das ist eigentlich nicht gemeint; es sieht nur so aus für ein Typargument. An anderer Stelle im Entwurf wird kommentiert, dass Sie nur einen Vertrag pro Funktion haben können, und hier kommt der Hauptunterschied ins Spiel. Verträge sind eigentlich Aussagen über die Typen der Funktion, nicht nur die Typen unabhängig voneinander. Zum Beispiel, wenn Sie haben

func Example(type K, V someContract)(k K, v V) V

du kannst sowas machen

contract someContract(k K, v V) {
  k.someMethod(v)
}

Dies vereinfacht die Koordination mehrerer Typen erheblich, ohne dass die Typen in der Funktionssignatur redundant angegeben werden müssen. Denken Sie daran, dass sie versuchen, das „merkwürdig wiederholende generische Muster“ zu vermeiden. Dieselbe Funktion mit parametrisierten Schnittstellen, die zum Einschränken der Typen verwendet wird, wäre beispielsweise so etwas wie

type someMethoder(V) interface {
  someMethod(V)
}

func Example(type K: someMethoder(V), V)(k K, v V) V

Das ist irgendwie umständlich. Die Vertragssyntax ermöglicht Ihnen dies jedoch bei Bedarf, da die „Argumente“ des Vertrags vom Compiler automatisch ausgefüllt werden, wenn der Vertrag die gleiche Anzahl von Argumenten hat wie die Funktion Parameter typisiert. Sie können sie jedoch manuell angeben, wenn Sie möchten, was bedeutet, dass Sie func Example(type K, V someContract(K, V))(k K, v V) V tun _könnten_, wenn Sie es wirklich wollten, obwohl dies in dieser Situation nicht besonders nützlich ist.

Eine Möglichkeit, klarer zu machen, dass es bei Verträgen um ganze Funktionen und nicht um einzelne Argumente geht, wäre, sie einfach anhand des Namens zuzuordnen. Beispielsweise,

contract Example(k K, v V) {
  k.someMethod(v)
}

func Example(type K, V)(k K, v V) V

wäre das gleiche wie oben. Der Nachteil ist jedoch, dass Verträge nicht wiederverwendbar sind und Sie die Möglichkeit verlieren, die Vertragsargumente manuell anzugeben.

Bearbeiten: Um weiter zu zeigen, warum sie das merkwürdig sich wiederholende Muster lösen wollen, betrachten Sie das Problem des kürzesten Pfads, auf das sie sich immer wieder bezogen. Bei parametrisierten Schnittstellen sieht die Definition am Ende so aus

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 { ... }

Mir persönlich gefällt eher die Art und Weise, wie Verträge für Funktionen spezifiziert werden. Ich bin nicht _zu_ scharf darauf, nur 'normale' Funktionskörper als eigentliche Vertragsspezifikation zu haben, aber ich denke, viele der potenziellen Probleme könnten gelöst werden, indem man eine Art gofmt-ähnlichen Vereinfacher einführt, der Verträge für Sie automatisch vereinfacht und entfernt Fremdteile. Dann _könnten_ Sie einfach einen Funktionskörper hineinkopieren, vereinfachen und von dort aus modifizieren. Ich bin mir aber leider nicht sicher, wie es möglich sein wird, dies zu implementieren.

Einige Dinge werden jedoch immer noch etwas umständlich zu spezifizieren sein, und die offensichtliche Überschneidung zwischen Verträgen und Schnittstellen erscheint immer noch etwas seltsam.

Ich finde die "CRTP"-Version viel klarer, expliziter und einfacher zu handhaben (keine Notwendigkeit, Verträge zu erstellen, die nur existieren, um die Beziehung zwischen bereits bestehenden Verträgen über eine Reihe von Variablen zu definieren). Zugegeben, das könnte auch nur an der langjährigen Vertrautheit mit der Idee liegen.

Erläuterungen. Durch den Entwurfsentwurf kann Vertrag auf beide Funktionen und Typen angewendet werden.

"""
Es ist wohl einfacher, wenn Sie nur Schnittstellen oder Verträge verwenden müssen, aber komplexer, wenn Sie beide zusammen verwenden müssen.
"""

Solange sie es Ihnen erlauben, innerhalb eines Vertrags auf eine oder mehrere Schnittstellen zu verweisen (anstatt nur auf Operatoren und Funktionen, wodurch DRY zugelassen wird), wird dieses Problem (und meine Behauptung) gelöst. Es besteht die Möglichkeit, dass ich das Vertragsmaterial falsch gelesen oder nicht vollständig gelesen habe, und es besteht auch die Möglichkeit, dass die genannte Funktion unterstützt wird und ich es nicht bemerkt habe. Wenn nicht, sollte es sein.

Können Sie Folgendes nicht tun?

contract Example(t T, v V) {
  t.(interface{
    SomeMethod() V
  })
}

Sie können keine an anderer Stelle deklarierte Schnittstelle verwenden, da Sie nicht auf Bezeichner aus demselben Paket verweisen können, in dem der Vertrag deklariert ist, aber Sie können dies tun. Oder sie könnten diese Einschränkung einfach aufheben; es wirkt etwas willkürlich.

@DeedleFake Nein, weil jeder Schnittstellentyp typgesichert werden kann (und dann zur Laufzeit möglicherweise nur in Panik gerät, aber Verträge nicht ausgeführt werden). Aber Sie können stattdessen eine Zuweisung verwenden.