CL https://golang.org/cl/22057 mentionne ce problème.

Permettez-moi de rappeler préventivement à tout le monde notre politique https://golang.org/wiki/NoMeToo . La fête des emoji est au-dessus.

Il y a Summary of Go Generics Discussions , qui tente de fournir un aperçu des discussions de différents endroits. Il fournit également quelques exemples de résolution de problèmes, où vous voudriez utiliser des génériques.

Il y a deux "exigences" dans la proposition liée qui peuvent compliquer la mise en œuvre et réduire la sécurité de type :

• Définissez des types génériques basés sur des types qui ne sont pas connus tant qu'ils ne sont pas instanciés.
• N'exige pas une relation explicite entre la définition d'un type ou d'une fonction générique et son utilisation. Autrement dit, les programmes ne devraient pas avoir à dire explicitement que le type T implémente le G générique.

Ces exigences semblent exclure par exemple un système similaire au système de traits de Rust, où les types génériques sont contraints par des limites de traits. Pourquoi sont-ils nécessaires ?

Il devient tentant de construire des génériques dans la bibliothèque standard à un niveau très bas, comme en C++ std::basic_string, std::allocateur>. Cela a ses avantages - sinon personne ne le ferait - mais cela a des effets étendus et parfois surprenants, comme dans des messages d'erreur C++ incompréhensibles.

Le problème en C++ provient de la vérification de type du code généré. Il doit y avoir une vérification de type supplémentaire avant la génération du code. La proposition de concepts C++ permet cela en permettant à l'auteur du code générique de spécifier les exigences d'un type générique. De cette façon, la compilation peut échouer à la vérification du type avant la génération du code et des messages d'erreur simples peuvent être imprimés. Le problème avec les génériques C++ (sans concepts) est que le code générique _est_ la spécification du type générique. C'est ce qui crée les messages d'erreur incompréhensibles.

Le code générique ne doit pas être la spécification d'un type générique.

@tamird C'est une caractéristique essentielle des types d'interface de Go que vous pouvez définir un type non d'interface T et définir ultérieurement un type d'interface I tel que T implémente I. Voir https://golang.org/doc/faq#implements_interface . Ce serait incohérent si Go implémentait une forme de génériques pour lesquels un type générique G ne pouvait être utilisé qu'avec un type T qui disait explicitement "Je peux être utilisé pour implémenter G".

Je ne connais pas Rust, mais je ne connais aucun langage qui oblige T à déclarer explicitement qu'il peut être utilisé pour implémenter G. Les deux exigences que vous mentionnez ne signifient pas que G ne peut pas imposer d'exigences à T, juste car I impose des exigences à T. Les exigences signifient simplement que G et T peuvent être écrits indépendamment. C'est une fonctionnalité hautement souhaitable pour les génériques, et je ne peux pas imaginer l'abandonner.

@ianlancetaylor https://doc.rust-lang.org/book/traits.html explique les traits de Rust. Bien que je pense qu'ils soient un bon modèle en général, ils conviendraient mal au Go tel qu'il existe aujourd'hui.

@sbunce J'ai aussi pensé que les concepts étaient la réponse, et vous pouvez voir l'idée dispersée à travers les différentes propositions avant la dernière. Mais il est décourageant que des concepts aient été initialement prévus pour ce qui est devenu C++11, et nous sommes maintenant en 2016, et ils sont toujours controversés et pas particulièrement proches d'être inclus dans le langage C++.

La littérature universitaire aurait-elle de la valeur pour des conseils sur l'évaluation des approches ?

Le seul article que j'ai lu sur le sujet est Les développeurs bénéficient-ils des types génériques ? (paywall désolé, vous pourriez chercher sur Google votre chemin vers un téléchargement pdf) qui avait ce qui suit à dire

Par conséquent, une interprétation conservatrice de l'expérience
est que les types génériques peuvent être considérés comme un compromis
entre les caractéristiques positives de la documentation et
caractéristiques d'extensibilité négatives. La partie excitante de
l'étude est qu'elle a montré une situation où l'utilisation d'un
système de type statique (plus fort) a eu un impact négatif sur la
temps de développement alors que dans le même temps le bénéfice attendu
fit - la réduction du temps de correction des erreurs de type - n'apparaissait pas.
Nous pensons que de telles tâches pourraient aider dans de futures expériences dans
identifier l'impact des systèmes de type.

Je vois également que https://github.com/golang/go/issues/15295 fait également référence à des génériques légers et flexibles orientés objet .

Si nous devions nous appuyer sur le milieu universitaire pour guider la décision, je pense qu'il serait préférable de faire une revue de la littérature en amont, et probablement de décider tôt si nous peserions les études empiriques différemment de celles reposant sur des preuves.

Veuillez consulter : http://dl.acm.org/citation.cfm?id=2738008 par Barbara Liskov :

La prise en charge de la programmation générique dans les langages de programmation modernes orientés objet est maladroite et manque de puissance expressive souhaitable. Nous introduisons un mécanisme de généricité expressive qui ajoute de la puissance expressive et renforce la vérification statique, tout en restant léger et simple dans les cas d'utilisation courants. Comme les classes de types et les concepts, le mécanisme permet aux types existants de modéliser rétroactivement les contraintes de type. Pour le pouvoir expressif, nous exposons les modèles en tant que constructions nommées qui peuvent être définies et sélectionnées explicitement pour témoigner des contraintes ; dans les utilisations courantes de la généricité, cependant, les types sont implicitement témoins de contraintes sans effort supplémentaire du programmeur.

Je pense que ce qu'ils ont fait là-bas est plutôt cool - je suis désolé si ce n'est pas le bon endroit pour s'arrêter mais je n'ai pas trouvé d'endroit pour commenter dans /proposals et je n'ai pas trouvé de problème approprié ici.

Il pourrait être intéressant d'avoir un ou plusieurs transpileurs expérimentaux - un code source générique Go vers un compilateur de code source Go 1.xy.
Je veux dire - trop de discussions/d'arguments pour mon opinion, et personne n'écrit de code source qui _essaye_ d'implémenter _une sorte_ de génériques pour Go.

Juste pour acquérir des connaissances et de l'expérience avec Go et les génériques - pour voir ce qui fonctionne et ce qui ne fonctionne pas.
Si toutes les solutions génériques Go ne sont pas vraiment bonnes, alors ; Pas de génériques pour Go.

La proposition peut-elle également inclure les implications sur la taille binaire et l'empreinte mémoire ? Je m'attendrais à ce qu'il y ait une duplication de code pour chaque type de valeur concrète afin que les optimisations du compilateur fonctionnent dessus. J'espère avoir la garantie qu'il n'y aura pas de duplication de code pour les types de pointeurs concrets.

Je propose une matrice de décision de Pugh. Mes critères incluent les impacts de visibilité (complexité de la source, taille). J'ai également forcé le classement des critères pour déterminer les poids des critères. Le vôtre peut bien sûr varier. J'ai utilisé "interfaces" comme alternative par défaut et j'ai comparé cela aux génériques "copier/coller", aux génériques basés sur des modèles (j'avais en tête quelque chose comme le fonctionnement du langage D) et quelque chose que j'ai appelé les génériques de style d'instanciation d'exécution. Je suis sûr que c'est une vaste simplification. Néanmoins, cela peut susciter quelques idées sur la façon d'évaluer les choix... cela devrait être un lien public vers ma feuille de calcul Google, ici

Pinging @yizhouzhang et @andrewcmyers afin qu'ils puissent exprimer leurs opinions sur les genres comme les génériques dans Go. Il semble que cela pourrait être un bon match :)

La conception des génériques que nous avons proposée pour Genus a une vérification de type statique et modulaire, ne nécessite pas de pré-déclarer que les types implémentent une interface et offre des performances raisonnables. Je l'examinerais certainement si vous songez à des génériques pour Go. Cela semble être un bon ajustement d'après ma compréhension de Go.

Voici un lien vers l'article qui ne nécessite pas l'accès à la bibliothèque numérique ACM :
http://www.cs.cornell.edu/andru/papers/genus/

La page d'accueil de Genus est ici : http://www.cs.cornell.edu/projects/genus/

Nous n'avons pas encore rendu public le compilateur, mais nous prévoyons de le faire assez bientôt.

Heureux de répondre à toutes les questions des gens.

En termes de matrice de décision de @mandolyte , Genus obtient un 17, à égalité au premier rang. J'ajouterais cependant quelques critères supplémentaires pour marquer. Par exemple, la vérification de type modulaire est importante, comme d'autres comme @sbunce observé ci-dessus, mais les schémas basés sur des modèles en manquent. Le rapport technique de l'article Genus contient un tableau beaucoup plus volumineux à la page 34, comparant diverses conceptions génériques.

Je viens de parcourir tout le document Summary of Go Generics , qui était un résumé utile des discussions précédentes. Le mécanisme des génériques dans Genus ne souffre pas, à mon avis, des problèmes identifiés pour C++, Java ou C#. Les génériques de genre sont réifiés, contrairement à Java, vous pouvez donc découvrir les types au moment de l'exécution. Vous pouvez également instancier sur des types primitifs, et vous n'obtenez pas de boxe implicite aux endroits où vous ne le souhaitez vraiment pas : des tableaux de T où T est une primitive. Le système de type est le plus proche de Haskell et Rust - en fait un peu plus puissant, mais je pense aussi intuitif. La spécialisation primitive comme C# n'est actuellement pas prise en charge dans Genus, mais elle pourrait l'être. Dans la plupart des cas, la spécialisation peut être déterminée au moment de la liaison, de sorte qu'une véritable génération de code d'exécution ne serait pas nécessaire.

CL https://golang.org/cl/22163 mentionne ce problème.

Un moyen de contraindre les types génériques qui ne nécessite pas l'ajout de nouveaux concepts de langage : https://docs.google.com/document/d/1rX4huWffJ0y1ZjqEpPrDy-kk-m9zWfatgCluGRBQveQ/edit?usp=sharing.

Genus a l'air vraiment cool et c'est clairement une avancée importante dans l'art, mais je ne vois pas comment cela s'appliquerait au Go. Quelqu'un a-t-il une esquisse de la façon dont il s'intégrerait au système/à la philosophie de type Go ?

Le problème est que l'équipe de go fait des tentatives d'obstruction. Le titre énonce clairement les intentions de l'équipe de go. Et si cela ne suffisait pas à dissuader tous les preneurs, les caractéristiques exigées d'un domaine aussi vaste dans les propositions d'ian indiquent clairement que si vous voulez des génériques, ils ne vous veulent pas. Il est stupide de tenter même de dialoguer avec l'équipe de go. A ceux qui recherchent des génériques en go, je dis fracturer le langage. Commencez un nouveau voyage - beaucoup suivront. J'ai déjà vu du bon travail dans les forks. Organisez-vous, rassemblez-vous autour d'une cause

Si quelqu'un veut essayer de créer une extension générique pour Go basée sur la conception Genus, nous sommes heureux de vous aider. Nous ne connaissons pas assez Go pour produire un design qui s'harmonise avec le langage existant. Je pense que la première étape serait une proposition de conception d'homme de paille avec des exemples élaborés.

@andrewcmyers en espérant que @ianlancetaylor travaillera avec vous là-dessus. Le simple fait d'avoir quelques exemples à regarder aiderait beaucoup.

J'ai lu l'article Genus. Dans la mesure où je le comprends, cela semble bien pour Java, mais ne semble pas être un choix naturel pour Go.

Un aspect clé de Go est que lorsque vous écrivez un programme Go, la plupart de ce que vous écrivez est du code. Ceci est différent de C++ et Java, où une grande partie de ce que vous écrivez est constituée de types. Le genre semble concerner principalement les types : vous écrivez des contraintes et des modèles, plutôt que du code. Le système de type de Go est très très simple. Le système de types de Genus est beaucoup plus complexe.

Les idées de modélisation rétroactive, bien que clairement utiles pour Java, ne semblent pas du tout convenir à Go. Les utilisateurs utilisent déjà des types d'adaptateurs pour faire correspondre les types existants aux interfaces ; rien de plus ne devrait être nécessaire lors de l'utilisation de génériques.

Il serait intéressant de voir ces idées appliquées au Go, mais je ne suis pas optimiste quant au résultat.

Je ne suis pas un expert en Go, mais son système de type ne semble pas plus simple que Java pré-générique. La syntaxe de type est un peu plus légère mais la complexité sous-jacente semble à peu près la même.

Dans Genus, les contraintes sont des types mais les modèles sont du code. Les modèles sont des adaptateurs, mais ils s'adaptent sans ajouter une couche d'emballage réel. Ceci est très utile lorsque vous souhaitez, par exemple, adapter un tableau entier d'objets à une nouvelle interface. La modélisation rétroactive vous permet de traiter le tableau comme un tableau d'objets satisfaisant l'interface souhaitée.

Je ne serais pas surpris s'il était plus compliqué que Java (pré-générique) dans un sens théorique de type, même s'il est plus simple à utiliser dans la pratique.

Mis à part la complexité relative, ils sont suffisamment différents pour que Genus ne puisse pas cartographier 1: 1. Aucun sous-typage ne semble être un gros.

Si vous êtes intéressé:

Le résumé le plus bref des différences philosophiques / de conception pertinentes que j'ai mentionnées est contenu dans les entrées suivantes de la FAQ :

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

Contrairement à la plupart des langages, la spécification Go est très courte et claire sur les propriétés pertinentes du système de type à partir de https://golang.org/ref/spec#Constants et continue jusqu'à la section intitulée "Blocs" (qui compte moins de 11 pages imprimées).

Contrairement aux génériques Java et C#, le mécanisme des génériques Genus n'est pas basé sur le sous-typage. Par contre, il me semble que Go a bien du sous-typage, mais du sous-typage structurel. C'est également un bon match pour l'approche Genus, qui a une saveur structurelle plutôt que de s'appuyer sur des relations prédéclarées.

Je ne crois pas que Go ait un sous-typage structurel.

Alors que deux types dont le type sous-jacent est identique sont donc identiques
peuvent être substitués l'un à l'autre, https://play.golang.org/p/cT15aQ-PFr

Cela ne s'étend pas à deux types qui partagent un sous-ensemble commun de champs,
https://play.golang.org/p/KrC9_BDXuh.

Le jeudi 28 avril 2016 à 13h09, Andrew Myers [email protected]
a écrit:

Contrairement aux génériques Java et C#, le mécanisme des génériques Genus ne repose pas sur
sous-typage. D'un autre côté, il me semble que Go a un sous-typage,
mais sous-typage structurel. C'est aussi un bon match pour l'approche genre,
qui a une saveur structurelle plutôt que de s'appuyer sur des prédéclarés
des relations.

—
Vous recevez ceci parce que vous êtes abonné à ce fil.
Répondez directement à cet e-mail ou consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment -215298127

Merci, j'interprétais mal une partie du langage sur le moment où les types implémentent des interfaces. En fait, il me semble que les interfaces Go, avec une extension modeste, pourraient être utilisées comme contraintes de style Genus.

C'est exactement pourquoi je vous ai envoyé un ping, le genre semble être une bien meilleure approche que Java/C# comme les génériques.

Il y avait quelques idées concernant la spécialisation sur les types d'interfaces ; par exemple, les "propositions" de l'approche _package templates_ 1 2 en sont des exemples.

tl;dr; le package générique avec spécialisation d'interface ressemblerait à :

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

Version 1. avec spécialisation étendue au package :

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. la spécialisation portée par la déclaration :

package main
import set

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

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

Les génériques à portée de paquet empêcheront les gens d'abuser de manière significative du système de génériques, puisque l'utilisation est limitée aux algorithmes de base et aux structures de données. Cela empêche essentiellement la création de nouvelles abstractions de langage et de code fonctionnel.

La spécialisation dans la portée de la déclaration a plus de possibilités au prix, ce qui la rend plus sujette aux abus et elle est plus détaillée. Mais, un code fonctionnel serait possible, par exemple :

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

L'approche de spécialisation d'interface a des propriétés intéressantes :

• Les packages déjà existants utilisant des interfaces seraient spécialisables. par exemple, je pourrais appeler sort.Sort[[Interface:MyItems]](...) et faire en sorte que le tri fonctionne sur le type concret au lieu de l'interface (avec des gains potentiels de l'inlining).
• Les tests sont simplifiés, je n'ai qu'à m'assurer que le code générique fonctionne avec les interfaces.
• Il est facile de dire comment cela fonctionne. c'est-à-dire imaginez que [[E: int]] remplace toutes les déclarations de E par int .

Cependant, il existe des problèmes de verbosité lorsque vous travaillez sur plusieurs packages :

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

_Bien sûr, le tout est plus simple à énoncer qu'à mettre en œuvre. En interne, il y a probablement des tonnes de problèmes et de façons dont cela pourrait fonctionner._

_PS, aux grincheux sur la lenteur des progrès des génériques, j'applaudis l'équipe Go pour avoir passé plus de temps sur des problèmes qui ont un plus grand avantage pour la communauté, par exemple les bogues du compilateur/d'exécution, SSA, GC, http2._

@egonelbre votre argument selon lequel les génériques au niveau du package empêcheront les "abus" est très important et je pense que la plupart des gens l'ignorent. Cela, ajouté à leur relative simplicité sémantique et syntaxique (seules les constructions package et import sont affectées), les rend très attractifs pour Go.

@andrewcymyers intéressant que vous pensiez que les interfaces Go fonctionnent comme des contraintes de style Genus. J'aurais pensé qu'ils ont toujours le problème que vous ne pouvez pas exprimer de contraintes multi-types avec eux.

Une chose que je viens de réaliser, cependant, c'est que dans Go, vous pouvez écrire une interface en ligne. Ainsi, avec la bonne syntaxe, vous pouvez placer l'interface dans la portée de tous les paramètres et capturer les contraintes multi-paramètres :

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

Je pense que le plus gros problème avec les interfaces en tant que contraintes est que les méthodes ne sont pas aussi répandues en Go qu'en Java. Les types intégrés n'ont pas de méthodes. Il n'y a pas d'ensemble de méthodes universelles comme celles de java.lang.Object. Les utilisateurs ne définissent généralement pas de méthodes telles que Equals ou HashCode sur leurs types à moins qu'ils n'en aient spécifiquement besoin, car ces méthodes ne qualifient pas un type à utiliser comme clés de carte ou dans tout algorithme nécessitant une égalité.

(L'égalité dans Go est une histoire intéressante. Le langage donne votre type "==" s'il répond à certaines exigences (voir https://golang.org/ref/spec#Logical_operators, recherchez "comparable"). Tout type avec " ==" peut servir de clé de carte. Mais si votre type ne mérite pas "==", alors il n'y a rien que vous puissiez écrire qui le fera fonctionner comme clé de carte.)

Étant donné que les méthodes ne sont pas omniprésentes et qu'il n'existe aucun moyen simple d'exprimer les propriétés des types intégrés (comme les opérateurs avec lesquels ils fonctionnent), j'ai suggéré d'utiliser le code lui-même comme mécanisme de contrainte générique. Voir le lien dans mon commentaire du 18 avril, ci-dessus. Cette proposition a ses problèmes, mais une fonctionnalité intéressante est que le code numérique générique pourrait toujours utiliser les opérateurs habituels, au lieu d'appels de méthode encombrants.

L'autre façon de faire est d'ajouter des méthodes aux types qui en manquent. Vous pouvez le faire dans le langage existant de manière beaucoup plus légère qu'en Java :

taper Entier entier
func (i Int) Less(j Int) bool { return i < j }

Le type Int « hérite » de tous les opérateurs et autres propriétés de int. Bien que vous deviez lancer entre les deux pour utiliser Int et int ensemble, ce qui peut être pénible.

Les modèles de genre pourraient aider ici. Mais il faudrait les garder très simples. Je pense que @ianlancetaylor était trop étroit dans sa caractérisation de Go comme écrivant plus de code, moins de types. Le principe général est que Go a horreur de la complexité. Nous regardons Java et C++ et sommes déterminés à ne jamais y aller. (Sans vouloir vous offenser.)

Donc, une idée rapide pour une fonctionnalité de type modèle serait : demandez à l'utilisateur d'écrire des types comme Int ci-dessus, et dans les instanciations génériques, autorisez "int avec Int", ce qui signifie utiliser le type int mais le traiter comme Int. Ensuite, il n'y a pas de construction de langage ouverte appelée modèle, avec son mot-clé, sa sémantique d'héritage, etc. Je ne comprends pas assez bien les modèles pour savoir si c'est faisable, mais c'est plus dans l'esprit du Go.

@jba Nous sommes certainement d'accord avec le principe d'éviter la complexité. "Aussi simple que possible mais pas plus simple." Je laisserais probablement certaines fonctionnalités Genus hors de Go pour ces raisons, du moins au début.

L'un des avantages de l'approche Genus est qu'elle gère les types intégrés de manière fluide. Rappelez-vous que les types primitifs en Java n'ont pas de méthodes, et Genus hérite de ce comportement. Au lieu de cela, Genus traite les types primitifs _comme s'ils avaient une suite assez large de méthodes dans le but de satisfaire les contraintes. Une table de hachage nécessite que ses clés puissent être hachées et comparées, mais tous les types primitifs satisfont à cette contrainte. Ainsi, les instanciations de type comme Map[int, boolean] sont parfaitement légales sans autre problème. Il n'est pas nécessaire de faire la distinction entre deux saveurs d'entiers (int vs Int) pour y parvenir. Cependant, si int n'était pas équipé de suffisamment d'opérations pour certaines utilisations, nous utiliserions un modèle presque exactement comme l'utilisation de Int ci-dessus.

Une autre chose qui mérite d'être mentionnée est l'idée de "modèles naturels" dans Genus. Normalement, vous n'avez pas besoin de déclarer un modèle pour utiliser un type générique : si l'argument de type satisfait la contrainte, un modèle naturel est automatiquement généré. Notre expérience est que c'est le cas habituel; déclarer des modèles nommés explicites n'est normalement pas nécessaire. Mais si un modèle était nécessaire - par exemple, si vous vouliez hacher des entiers de manière non standard - alors la syntaxe est similaire à ce que vous avez suggéré : Map[int with fancyHash, boolean] . Je dirais que Genus est syntaxiquement léger dans les cas d'utilisation normaux, mais avec de la puissance en réserve en cas de besoin.

@egonelbre Ce que vous proposez ici ressemble à des types virtuels, qui sont pris en charge par Scala. Il existe un article ECOOP'97 de Kresten Krab Thorup, "Genericity in Java with virtual types", qui explore cette direction. Nous avons également développé des mécanismes pour les types virtuels et les classes virtuelles dans notre travail (« J& : nested intersection for scalable software composition », OOPSLA'06).

Étant donné que les initialisations littérales sont omniprésentes dans Go, je devais me demander à quoi ressemblerait une fonction littérale. Je soupçonne que le code pour gérer cela existe en grande partie dans Go générer, corriger et renommer. Peut-être que cela inspirera quelqu'un :-)

// la définition (générique) du type de fonction
type Somme64 fonction (X, Y) float64 {
retour float64(X) + float64(Y)
}

// en instancie un, positionnellement
je := 42
var j uint = 86
somme := &Somme64{i, j}

// en instancie un, par des types de paramètres nommés
somme := &Sum64{ X : int, Y : uint}

// maintenant l'utiliser...
result := sum(i, j) // le résultat est 128

La proposition d'Ian en demande trop. Nous ne pouvons pas développer toutes les fonctionnalités en même temps, il existera dans un état inachevé pendant plusieurs mois.

En attendant, le projet inachevé ne peut pas être qualifié de langage Go officiel tant qu'il n'est pas terminé, car cela risquerait de fragmenter l'écosystème.

La question est donc de savoir comment planifier cela.

Une grande partie du projet consisterait également à développer le corpus de référence.
développer les collections génériques réelles, les algorithmes et d'autres choses de telle manière que nous sommes tous d'accord sur le fait qu'ils sont idiomatiques, tout en utilisant les nouvelles fonctionnalités go 2.0

Une syntaxe possible ?

// 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 , la syntaxe n'est pas la partie la plus difficile de ce problème. En fait, c'est de loin le plus simple. Veuillez consulter la discussion et les documents liés ci-dessus.

@ md2perpe Nous avons discuté du paramétrage de packages entiers ("modules") comme moyen de généricité en interne - cela semble être un moyen de réduire la surcharge syntaxique. Mais il a d'autres problèmes; par exemple, il n'est pas clair comment le paramétrer avec des types qui ne sont pas au niveau du package. Mais l'idée peut encore valoir la peine d'être explorée en détail.

J'aimerais partager une perspective : dans un univers parallèle, toutes les signatures de fonction Go ont toujours été contraintes de ne mentionner que les types d'interface, et au lieu de la demande de génériques aujourd'hui, il y en a un pour éviter l'indirection associée aux valeurs d'interface. Pensez à la façon dont vous résoudriez ce problème (sans changer la langue). J'ai quelques idées.

@thwd Ainsi, l'auteur de la bibliothèque continuerait-il à utiliser des interfaces, mais sans le changement de type et les assertions de type nécessaires aujourd'hui. Et l'utilisateur de la bibliothèque passerait-il simplement des types concrets comme si la bibliothèque utilisait les types tels quels... et alors le compilateur réconcilierait-il les deux ? Et s'il ne pouvait pas dire pourquoi ? (comme l'opérateur modulo a été utilisé dans la bibliothèque, mais l'utilisateur a fourni une tranche de quelque chose.

Suis-je proche ? :-)

@mandolyte oui ! échangeons des mails pour ne pas polluer ce fil. Vous pouvez me joindre à « me at thwd dot me ». Toute autre personne lisant ceci qui pourrait être intéressée; Envoyez-moi un e-mail et je vous ajouterai au fil de discussion.

C'est une excellente fonctionnalité pour type system et collection library .
Une syntaxe potentielle :

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

Pour interface

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

super type ou type implement :

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

Le ci-dessus aka en java:

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

@leaxoy comme dit précédemment, la syntaxe n'est pas la partie la plus difficile ici. Voir la discussion ci-dessus.

Sachez simplement que le coût de l'interface est incroyablement énorme.

Veuillez expliquer pourquoi pensez-vous que le coût de l'interface est "incroyablement"
grande.
Cela ne devrait pas être pire que les appels virtuels non spécialisés de C++.

@minux Je ne peux pas dire sur les coûts de performance mais par rapport à la qualité du code. interface{} ne peut pas être vérifié au moment de la compilation, mais les génériques le peuvent. À mon avis, c'est, dans la plupart des cas, plus important que les problèmes de performances liés à l'utilisation de interface{} .

@xoviat

Il n'y a vraiment aucun inconvénient à cela car le traitement requis pour cela ne ralentit pas le compilateur.

Il y a (au moins) deux inconvénients.

L'un est un travail accru pour l'éditeur de liens : si les spécialisations pour deux types aboutissent au même code machine sous-jacent, nous ne voulons pas compiler et lier deux copies de ce code.

Une autre est que les packages paramétrés sont moins expressifs que les méthodes paramétrées. (Voir les propositions liées au premier commentaire pour plus de détails.)

L'hypertype est-il une bonne idée ?

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

L'hypertype est-il une bonne idée ?

Ce que vous décrivez ici n'est qu'un paramétrage de type à la C++ (c'est-à-dire des modèles). Il ne vérifie pas le type de manière modulaire car il n'y a aucun moyen de savoir que le type aType a une opération + à partir des informations fournies. Le paramétrage de type contraint comme dans CLU, Haskell, Java, Genus est la solution.

@ golang101 J'ai une proposition détaillée dans ce sens. Je vais envoyer un CL pour l'ajouter à la liste, mais il est peu probable qu'il soit adopté.

CL https://golang.org/cl/38731 mentionne ce problème.

@andrewcmyers

Il ne vérifie pas le type de manière modulaire car il n'y a aucun moyen de savoir que le type aType a une opération + à partir des informations fournies.

Bien sûr qu'il y en a. Cette contrainte est implicite dans la définition de la fonction, et les contraintes de cette forme peuvent être propagées à tous les appelants (transitifs) au moment de la compilation de getAddFunc .

La contrainte ne fait pas partie d'un Go _type_ — c'est-à-dire qu'elle ne peut pas être encodée dans le système de type de la partie d'exécution du langage — mais cela ne signifie pas qu'elle ne peut pas être évaluée de manière modulaire.

Ajout de ma proposition en tant que 2016-09-compile-time-functions.md .

Je ne m'attends pas à ce qu'il soit adopté, mais il peut au moins servir de référence intéressante.

@bcmills Je pense que les fonctions de temps de compilation sont une idée puissante, en dehors de toute considération de génériques. Par exemple, j'ai écrit un solveur de sudoku qui a besoin d'un popcount. Pour accélérer cela, j'ai précalculé les popcounts pour les différentes valeurs possibles et je l'ai stocké en tant que Go source . C'est quelque chose que l'on pourrait faire avec go:generate . Mais s'il y avait une fonction de temps de compilation, cette table de recherche pourrait tout aussi bien être calculée au moment de la compilation, évitant ainsi au code généré par la machine d'avoir à être validé dans le référentiel. En général, tout type de fonction mathématique mémorisable convient parfaitement aux tables de recherche prédéfinies avec des fonctions de temps de compilation.

Plus spéculativement, on pourrait aussi vouloir, par exemple, télécharger une définition de protobuf à partir d'une source canonique et l'utiliser pour construire des types au moment de la compilation. Mais peut-être que c'est trop pour être autorisé à faire au moment de la compilation ?

J'ai l'impression que les fonctions de compilation sont à la fois trop puissantes et trop faibles : elles sont trop flexibles et peuvent se tromper de manière étrange / ralentir la compilation comme le font les modèles C++, mais d'un autre côté, elles sont trop statiques et difficiles à s'adapter à des choses comme des fonctions de première classe.

Pour la deuxième partie, je ne vois pas comment créer quelque chose comme une "tranche de fonctions qui traitent des tranches d'un type particulier et renvoient un élément", ou dans une syntaxe ad hoc []func<T>([]T) T , qui est très facile à faire dans pratiquement tous les langages fonctionnels à typage statique. Ce qui est vraiment nécessaire, ce sont des valeurs capables de prendre des types paramétriques, et non une génération de code au niveau du code source.

@bunsim

Pour la deuxième partie, je ne vois pas comment créer quelque chose comme une "tranche de fonctions qui traitent des tranches d'un type particulier et renvoient un élément",

Si vous parlez d'un paramètre de type unique, dans ma proposition, cela s'écrirait:

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

Si vous parlez de mélanger des paramètres de type et des paramètres de valeur, non, ma proposition ne le permet pas : une partie de l'intérêt des fonctions de compilation est de pouvoir fonctionner sur des valeurs non encadrées, et le type de paramétricité d'exécution Je pense que vous décrivez à peu près nécessite la boxe des valeurs.

Oui, mais à mon avis, ce genre de chose qui nécessite une boxe devrait être autorisé tout en gardant la sécurité de type, peut-être avec une syntaxe spéciale qui indique la "boîte". Une grande partie de l'ajout de "génériques" consiste vraiment à éviter l'insécurité de type de interface{} même lorsque la surcharge de interface{} n'est pas évitable. (Peut-être n'autoriser que certaines constructions de type paramétrique avec des types de pointeur et d'interface qui sont "déjà" encadrés ? Les objets encadrés Integer etc. de Java ne sont pas complètement une mauvaise idée, bien que les tranches de types valeur soient délicates)

J'ai juste l'impression que les fonctions de compilation ressemblent beaucoup à C++ et seraient extrêmement décevantes pour des personnes comme moi qui s'attendent à ce que Go2 ait un système de type paramétrique moderne fondé sur une théorie de type sonore plutôt qu'un hack basé sur la manipulation de morceaux de code source écrit dans une langue sans génériques.

@bcmills
Ce que vous proposez ne sera pas modulaire. Si le module A utilise le module B, qui utilise le module C, qui utilise le module D, une modification de la façon dont un paramètre de type est utilisé dans D peut devoir se propager jusqu'à A, même si l'implémenteur de A n'a aucune idée que D est dans le système. Le couplage lâche fourni par les systèmes de modules sera affaibli et les logiciels seront plus fragiles. C'est l'un des problèmes des modèles C++.

Si, d'autre part, les signatures de type capturent les exigences sur les paramètres de type, comme dans des langages comme CLU, ML, Haskell ou Genus, un module peut être compilé sans aucun accès aux éléments internes des modules dont il dépend.

@bunsim

Une grande partie de l'ajout de "génériques" consiste vraiment à éviter l'insécurité de type d'interface{} même lorsque la surcharge d'interface{} n'est pas évitable.

"non évitable" est relatif. Notez que la surcharge de la boxe est le point n ° 3 dans le post de Russ de 2009 (https://research.swtch.com/generic).

s'attendre à ce que Go2 ait un système de type paramétrique moderne fondé sur une théorie de type sonore plutôt qu'un hack basé sur la manipulation de morceaux de code source

Une bonne "théorie des types sonores" est descriptive et non prescriptive. Ma proposition s'inspire en particulier du calcul lambda du second ordre (dans le sens du système F), où gotype représente le genre type et l'ensemble du système de type du premier ordre est hissé dans le second -types d'ordre ("compilation-time").

Il est également lié aux travaux sur la théorie des types modaux de Davies, Pfenning et al à la CMU. Pour un peu de contexte, je commencerais par A Modal Analysis of Staged Computation and Modal Types as Staging Specifications for Run-time Code Generation .

Il est vrai que la théorie des types sous-jacente à ma proposition est moins formellement spécifiée que dans la littérature académique, mais cela ne veut pas dire qu'elle n'y est pas.

@andrewcmyers

Si le module A utilise le module B, qui utilise le module C, qui utilise le module D, une modification de la façon dont un paramètre de type est utilisé dans D peut devoir se propager jusqu'à A, même si l'implémenteur de A n'a aucune idée que D est dans le système.

C'est déjà vrai dans Go aujourd'hui : si vous regardez attentivement, vous remarquerez que les fichiers objets générés par le compilateur pour un package Go donné incluent des informations sur les parties des dépendances transitives qui affectent l'API exportée.

Le couplage lâche fourni par les systèmes de modules sera affaibli et les logiciels seront plus fragiles.

J'ai entendu le même argument utilisé pour préconiser l'exportation de types interface plutôt que de types concrets dans les API Go, et l'inverse s'avère plus courant : l'abstraction prématurée surcontraint les types et entrave l'extension des API. (Pour un tel exemple, voir # 19584.) Si vous voulez vous appuyer sur cette ligne d'argumentation, je pense que vous devez fournir des exemples concrets.

C'est l'un des problèmes des modèles C++.

Comme je le vois, les principaux problèmes avec les modèles C++ sont (sans ordre particulier):

• Ambiguïté syntaxique excessive.
  une. Ambiguïté entre les noms de type et les noms de valeur.
  b. Prise en charge excessivement large de la surcharge de l'opérateur, entraînant une capacité affaiblie à déduire les contraintes de l'utilisation de l'opérateur.
• Dépendance excessive à la résolution de surcharge pour la métaprogrammation (ou, de manière équivalente, évolution ad hoc de la prise en charge de la métaprogrammation).
  une. Surtout par rapport aux règles d'effondrement des références.
• Application trop large du principe SFINAE, conduisant à des contraintes très difficiles à propager et beaucoup trop de conditions implicites dans les définitions de type, conduisant à un rapport d'erreur très difficile.
• Utilisation excessive du collage de jetons et de l'inclusion textuelle (le préprocesseur C) au lieu de la substitution AST et des artefacts de compilation d'ordre supérieur (qui, heureusement, semblent être au moins en partie résolus avec les modules).
• Manque de bons langages d'amorçage pour les compilateurs C++, entraînant un mauvais rapport d'erreurs dans les lignées de compilateurs de longue durée (par exemple, la chaîne d'outils GCC).
• Le doublement (et parfois la multiplication) des noms résultant du mappage d'ensembles d'opérateurs sur des "concepts" nommés différemment (plutôt que de traiter les opérateurs eux-mêmes comme les contraintes fondamentales).

Je code en C++ par intermittence depuis une décennie maintenant et je suis heureux de discuter longuement des lacunes de C++, mais le fait que les dépendances de programme soient transitives n'a jamais figuré en haut de ma liste de plaintes.

D'un autre côté, avoir besoin de mettre à jour une chaîne de dépendances O(N) juste pour ajouter une seule méthode à un type dans le module A et pouvoir l'utiliser dans le module D ? C'est le genre de problème qui me ralentit régulièrement. Là où la paramétricité et le couplage lâche sont en conflit, je choisirai la paramétricité n'importe quel jour.

Pourtant, je crois fermement que la métaprogrammation et le polymorphisme paramétrique doivent être séparés, et la confusion de C++ entre eux est la cause première de la raison pour laquelle les modèles C++ sont ennuyeux. En termes simples, C++ tente d'implémenter une idée de théorie des types en utilisant essentiellement des macros sur des stéroïdes, ce qui est très problématique puisque les programmeurs aiment considérer les modèles comme un véritable polymorphisme paramétrique et sont frappés par un comportement inattendu. Les fonctions de compilation sont une excellente idée pour la métaprogrammation et le remplacement du hack qui est go generate , mais je ne pense pas que cela devrait être la manière bénie de faire de la programmation générique.

Le polymorphisme paramétrique "réel" facilite le couplage lâche et ne devrait pas entrer en conflit avec lui. Il devrait également être étroitement intégré au reste du système de type; par exemple, il devrait probablement être intégré dans le système d'interface actuel, de sorte que de nombreuses utilisations des types d'interface pourraient être réécrites dans des éléments tels que :

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

ce qui devrait éviter la surcharge de l'interface (comme l'utilisation de Rust), bien que dans ce cas ce ne soit pas très utile.

Un meilleur exemple pourrait être le package sort , où vous pourriez avoir quelque chose comme

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

où Comparable est simplement une bonne vieille interface que les types peuvent implémenter. Sort peut ensuite être appelé sur une tranche de types valeur qui implémentent Comparable , sans les enfermer dans des types d'interface.

@bcmills Les dépendances transitives non contraintes par le système de type sont, à mon avis, au cœur de certaines de vos plaintes concernant C++. Les dépendances transitives ne sont pas vraiment un problème si vous contrôlez les modules A, B, C et D. En général, vous développez le module A et ne savez peut-être que faiblement que le module D est là-bas, et inversement, le développeur de D peut ignorer A. Si le module D maintenant, sans apporter de modification aux déclarations visibles dans D, commence à utiliser un nouvel opérateur sur un paramètre de type - ou utilise simplement ce paramètre de type comme argument de type à un nouveau module E avec son propre contraintes implicites - ces contraintes se répercuteront sur tous les clients, qui n'utiliseront peut-être pas d'arguments de type satisfaisant aux contraintes. Rien ne dit au développeur D qu'ils le font exploser. En effet, vous avez une sorte d'inférence de type globale, avec toutes les difficultés de débogage que cela implique.

Je pense que l'approche que nous avons adoptée dans Genus [ PLDI'15 ] est bien meilleure. Les paramètres de type ont des contraintes explicites, mais légères (je prends note de votre point de vue sur la prise en charge des contraintes d'opération ; CLU a montré comment faire cela dès 1977). La vérification de type Genre est entièrement modulaire. Le code générique peut soit être compilé une seule fois pour optimiser l'espace de code, soit être spécialisé sur des arguments de type particuliers pour de bonnes performances.

@andrewcmyers

Si le module D maintenant, sans apporter de modification aux déclarations visibles dans D, commence à utiliser un nouvel opérateur sur un paramètre de type […] [clients] peut ne pas utiliser d'arguments de type satisfaisant aux contraintes. Rien ne dit au développeur D qu'ils le font exploser.

Bien sûr, mais c'est déjà vrai pour de nombreuses contraintes implicites dans Go, indépendamment de tout mécanisme de programmation générique.

Par exemple, une fonction peut recevoir un paramètre de type interface et appeler initialement ses méthodes séquentiellement. Si cette fonction change ultérieurement pour appeler ces méthodes simultanément (en engendrant des goroutines supplémentaires), la contrainte "doit être sûre pour une utilisation simultanée" n'est pas reflétée dans le système de type.

De même, le système de type Go aujourd'hui ne spécifie pas de contraintes sur les durées de vie des variables : certaines implémentations de io.Writer supposent à tort qu'elles peuvent conserver une référence à la tranche transmise et la lire plus tard (par exemple en effectuant l'écriture réelle de manière asynchrone dans une goroutine d'arrière-plan), mais cela provoque des courses de données si l'appelant de Write tente de réutiliser la même tranche de sauvegarde pour un Write suivant.

Ou une fonction utilisant un commutateur de type peut prendre un chemin différent d'une méthode est ajoutée à l'un des types dans le commutateur.

Ou une fonction vérifiant un code d'erreur particulier peut s'arrêter si la fonction générant l'erreur change la façon dont elle signale cette condition. (Par exemple, voir https://github.com/golang/go/issues/19647.)

Ou une fonction vérifiant un type d'erreur particulier peut se briser si des wrappers autour de l'erreur sont ajoutés ou supprimés (comme cela s'est produit dans le package standard net dans Go 1.5).

Ou la mise en mémoire tampon sur un canal exposé dans une API peut changer, introduisant des blocages et/ou des courses.

...etc.

Go n'est pas inhabituel à cet égard : les contraintes implicites sont omniprésentes dans les programmes du monde réel.

Si vous essayez de capturer toutes les contraintes pertinentes dans des annotations explicites, vous finissez par aller dans l'une des deux directions.

Dans un sens, vous construisez un système complexe et extrêmement complet de types et d'annotations dépendants, et les annotations finissent par récapituler une partie substantielle du code qu'elles annotent. Comme j'espère que vous pouvez le voir clairement, cette direction n'est pas du tout conforme à la conception du reste du langage Go : Go privilégie la simplicité des spécifications et la concision du code par rapport au typage statique complet.

Dans l'autre sens, les annotations explicites ne couvriraient qu'un sous-ensemble des contraintes pertinentes pour une API donnée. Désormais, les annotations fournissent un faux sentiment de sécurité : le code peut toujours se casser en raison de modifications des contraintes implicites, mais la présence de contraintes explicites induit le développeur en erreur en lui faisant croire que toute modification « type-safe » maintient également la compatibilité.

Je ne comprends pas pourquoi ce type de stabilité de l'API doit être réalisé via une annotation explicite du code source : le type de stabilité de l'API que vous décrivez peut également être obtenu (avec moins de redondance dans le code) via l'analyse du code source. Par exemple, vous pouvez imaginer que l' outil api analyse le code et génère un ensemble de contraintes beaucoup plus riche que celui qui peut être exprimé dans le système de type formel du langage, et donne à l' outil guru le possibilité d'interroger l'ensemble calculé de contraintes pour une fonction, une méthode ou un paramètre d'API donné.

@bcmills Ne faites-vous pas du parfait l'ennemi du bien ? Oui, il existe des contraintes implicites difficiles à capturer dans un système de type. (Et une bonne conception modulaire évite d'introduire de telles contraintes implicites lorsque cela est possible). font des erreurs. Même avec les progrès récents en matière de diagnostic et de localisation automatiques des erreurs , je ne retiens pas mon souffle. D'une part, les outils d'analyse ne peuvent analyser que le code que vous leur fournissez. Les développeurs n'ont pas toujours accès à tout le code qui pourrait être lié au leur.

Alors, là où il y a des contraintes faciles à capturer dans un système de typage, pourquoi ne pas donner aux programmeurs la possibilité de les écrire ? Nous avons 40 ans d'expérience dans la programmation avec des paramètres de type contraints statiquement. Il s'agit d'une annotation statique simple et intuitive qui porte ses fruits.

Une fois que vous avez commencé à créer un logiciel plus volumineux qui superpose des modules logiciels, vous commencez à vouloir écrire des commentaires expliquant ces contraintes implicites de toute façon. En supposant qu'il existe un bon moyen vérifiable de les exprimer, pourquoi ne pas laisser le compilateur participer à la blague afin qu'il puisse vous aider?

Je note que certains de vos exemples d'autres contraintes implicites impliquent la gestion des erreurs. Je pense que notre vérification statique légère des exceptions [ PLDI 2016 ] traiterait ces exemples.

@andrewcmyers

Alors, là où il y a des contraintes faciles à capturer dans un système de typage, pourquoi ne pas donner aux programmeurs la possibilité de les écrire ?
[…]
Une fois que vous avez commencé à créer un logiciel plus volumineux qui superpose des modules logiciels, vous commencez à vouloir écrire des commentaires expliquant ces contraintes implicites de toute façon. En supposant qu'il existe un bon moyen vérifiable de les exprimer, pourquoi ne pas laisser le compilateur participer à la blague afin qu'il puisse vous aider?

En fait, je suis entièrement d'accord avec ce point, et j'utilise souvent un argument similaire en ce qui concerne la gestion de la mémoire. (Si vous devez de toute façon documenter des invariants sur le crénelage et la conservation des données, pourquoi ne pas appliquer ces invariants au moment de la compilation ?)

Mais je pousserais cet argument un peu plus loin : l'inverse est également vrai ! Si vous _n'avez pas_ besoin d'écrire un commentaire pour une contrainte (parce que c'est évident dans le contexte pour les humains qui travaillent avec le code), pourquoi devriez-vous avoir besoin d'écrire ce commentaire pour le compilateur ? Indépendamment de mes préférences personnelles, l'utilisation par Go de la récupération de place et des valeurs nulles indique clairement un parti pris pour "ne pas obliger les programmeurs à énoncer des invariants évidents". Il se peut que la modélisation de style Genus puisse exprimer bon nombre des contraintes qui seraient exprimées dans les commentaires, mais comment se comporte-t-elle en termes d'élidation des contraintes qui seraient également élidées dans les commentaires ?

Il me semble que les modèles de style Genus sont de toute façon plus que de simples commentaires : ils modifient en fait la sémantique du code dans certains cas, ils ne se contentent pas de le contraindre. Nous aurions maintenant deux mécanismes différents - les interfaces et les modèles de type - pour paramétrer les comportements. Cela représenterait un changement majeur dans le langage Go : nous avons découvert certaines bonnes pratiques pour les interfaces au fil du temps (telles que "définir les interfaces côté consommateur") et il n'est pas évident que cette expérience se traduirait par un système aussi radicalement différent, même en négligeant la compatibilité Go 1.

De plus, l'une des excellentes propriétés de Go est que sa spécification peut être lue (et largement comprise) en un après-midi. Il n'est pas évident pour moi qu'un système de contraintes de style Genus puisse être ajouté au langage Go sans le compliquer considérablement - je serais curieux de voir une proposition concrète de modifications de la spécification.

Voici un point de données intéressant pour la "métaprogrammation". Ce serait bien pour certains types dans les packages sync et atomic — à savoir, atomic.Value et sync.Map — de prendre en charge les méthodes CompareAndSwap , mais ceux-ci ne fonctionnent que pour les types qui se trouvent être comparables. Le reste des API atomic.Value et sync.Map restent utiles sans ces méthodes, donc pour ce cas d'utilisation, nous avons soit besoin de quelque chose comme SFINAE (ou d'autres types d'API définies de manière conditionnelle), soit nous devons tomber retour à une hiérarchie de types plus complexe.

Je veux abandonner cette idée de syntaxe créative d'utiliser l'écriture syllabique aborigène.

@bcmills Pouvez-vous expliquer plus en détail ces trois points ?

1. Ambiguïté entre les noms de type et les noms de valeur.
2. Prise en charge excessivement large de la surcharge des opérateurs
   3. Dépendance excessive à la résolution de surcharge pour la métaprogrammation

@mahdix Bien sûr.

1. Ambiguïté entre les noms de type et les noms de valeur.

Cet article donne une bonne introduction. Pour analyser un programme C++, vous devez savoir quels noms sont des types et lesquels sont des valeurs. Lorsque vous analysez un programme C++ basé sur un modèle, ces informations ne sont pas disponibles pour les membres des paramètres de modèle.

Un problème similaire se pose dans Go pour les littéraux composites, mais l'ambiguïté se situe entre les valeurs et les noms de champ plutôt qu'entre les valeurs et les types. Dans ce code Go :

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

a est-il un nom de champ littéral, ou est-ce la constante a utilisée comme clé de carte ou index de tableau ?

1. Prise en charge excessivement large de la surcharge des opérateurs

La recherche dépendante des arguments est un bon point de départ. Les surcharges d'opérateurs en C++ peuvent se produire en tant que méthodes sur le type de récepteur ou en tant que fonctions libres dans l'un des nombreux espaces de noms, et les règles de résolution de ces surcharges sont assez complexes.

Il existe de nombreuses façons d'éviter cette complexité, mais la plus simple (comme le fait actuellement Go) consiste à interdire complètement la surcharge de l'opérateur.

1. Dépendance excessive à la résolution de surcharge pour la métaprogrammation

La bibliothèque <type_traits> est un bon point de départ. Découvrez la mise en œuvre dans votre quartier convivial libc++ pour voir comment la résolution de surcharge entre en jeu.

Si Go prend en charge la métaprogrammation (et même cela est très douteux), je ne m'attendrais pas à ce qu'elle implique une résolution de surcharge comme opération fondamentale pour protéger les définitions conditionnelles.

@bcmills
Comme je n'ai jamais utilisé C++, pourriez-vous nous éclairer sur la surcharge d'opérateur via l'implémentation d'"interfaces" prédéfinies en termes de complexité. Python et Kotlin en sont des exemples.

Je pense qu'ADL lui-même est un énorme problème avec les modèles C++ qui n'ont pour la plupart pas été mentionnés, car ils obligent le compilateur à retarder la résolution de tous les noms jusqu'au moment de l'instanciation, et peuvent entraîner des bogues très subtils, en partie parce que "l'idéal" et " les compilateurs paresseux" se comportent différemment ici et la norme le permet. Le fait qu'il supporte la surcharge d'opérateurs n'est pas vraiment le pire de loin.

Cette proposition est basée sur des Templates, un système d'expansion macro ne suffirait-il pas ? Je ne parle pas de go generate ou de projets comme gottemplate. Je parle plus comme ça :

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

La macro pourrait réduire le passe-partout et l'utilisation de la réflexion.

Je pense que C++ est un assez bon exemple pour que les génériques ne soient pas basés sur des modèles ou des macros. Surtout si l'on considère que Go a des choses comme des fonctions anonymes qui ne peuvent vraiment pas être "instanciées" au moment de la compilation, sauf en tant qu'optimisation.

@samadadi , vous pouvez faire passer votre message sans dire "qu'est-ce qui ne va pas chez vous". Cela dit, l'argument de la complexité a déjà été évoqué plusieurs fois.

Go n'est pas le premier langage à essayer d'atteindre la simplicité en omettant la prise en charge du polymorphisme paramétrique (génériques), bien que cette fonctionnalité soit devenue de plus en plus importante au cours des 40 dernières années - d'après mon expérience, c'est un incontournable des cours de programmation du deuxième semestre.

Le problème de ne pas avoir la fonctionnalité dans le langage est que les programmeurs finissent par recourir à des solutions de contournement encore pires. Par exemple, les programmeurs Go écrivent souvent des modèles de code qui sont macro-étendus pour produire le "vrai" code pour divers types souhaités. Mais le vrai langage de programmation est celui que vous tapez, pas celui que le compilateur voit. Donc, cette stratégie signifie effectivement que vous utilisez un langage (qui n'est plus standard) qui a toute la fragilité et le gonflement du code des modèles C++.

Comme indiqué sur https://blog.golang.org/toward-go2 , nous devons fournir des "rapports d'expérience", afin que les besoins et les objectifs de conception puissent être déterminés. Pourriez-vous prendre quelques minutes et documenter les macro-cas que vous avez observés ?

Veuillez garder ce bogue sur le sujet et civil. Et encore une fois, https://golang.org/wiki/NoMeToo. Veuillez ne commenter que si vous avez des informations uniques et constructives à ajouter.

@mandolyte Il est très facile de trouver sur le web des explications détaillées prônant la génération de code comme substitut (partiel) aux génériques :
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/

De toute évidence, il y a beaucoup de gens qui adoptent cette approche.

@andrewcmyers , il existe certaines limitations ainsi que des mises en garde de commodité lors de l'utilisation de la génération de code MAIS .
Généralement - si vous pensez que cette approche est la meilleure/suffisante, je pense que l'effort de permettre une génération quelque peu similaire à partir de la chaîne d'outils go serait une bénédiction.

• L'optimisation du compilateur peut être un défi dans ce cas, mais l'exécution sera cohérente, ET la maintenance du code, l'expérience utilisateur (simplicité...) , les meilleures pratiques standard et les normes de code unifiées peuvent être conservées .
  De plus - toute la chaîne d'outils restera la même, à l'exception des outils de débogage (profileurs, débogueurs d'étape, etc.) qui verront des lignes de code qui n'ont pas été écrites par le développeur, mais c'est un peu comme entrer dans le code ASM pendant le débogage - seulement c'est un code lisible :) .

Inconvénient - aucun précédent (à ma connaissance) à cette approche dans la chaîne d'outils go.

Pour résumer, considérez la génération de code comme faisant partie du processus de construction, elle ne devrait pas être trop compliquée, assez sûre, optimisée pour l'exécution, peut conserver la simplicité et de très petits changements dans le langage.

IMHO : C'est un compromis facilement atteint, avec un prix bas.

Pour être clair, je ne considère pas que la génération de code de style macro, qu'elle soit effectuée avec gen, cpp, gofmt -r ou d'autres outils de macro/modèle, soit une bonne solution au problème des génériques, même si elle est standardisée. Il a les mêmes problèmes que les templates C++ : gonflement du code, manque de vérification de type modulaire et difficulté de débogage. Cela s'aggrave au fur et à mesure que vous commencez, comme c'est naturel, en construisant du code générique en termes d'autre code générique. À mon avis, les avantages sont limités : cela rendrait la vie relativement simple aux auteurs du compilateur Go et cela produirait un code efficace - à moins qu'il n'y ait une pression sur le cache d'instructions, une situation fréquente dans les logiciels modernes !

Je pense que le point était plutôt que la génération de code est utilisée pour remplacer
génériques, les génériques devraient donc chercher à résoudre la plupart de ces cas d'utilisation.

Le mercredi 26 juillet 2017, 22h41, Andrew Myers, [email protected] a écrit :

Pour être clair, je ne considère pas la génération de code de style macro, qu'elle soit effectuée
avec gen, cpp, gofmt -r ou d'autres outils de macro/modèle, pour être un bon
solution au problème des génériques même s'il est standardisé. Il a le même
problèmes en tant que modèles C++ : gonflement du code, manque de vérification de type modulaire et
difficulté de débogage. Cela s'aggrave au fur et à mesure que vous commencez, comme c'est naturel, à construire
code générique en termes d'autre code générique. Selon moi, les avantages sont
limité : cela garderait la vie relativement simple pour les auteurs du compilateur Go
et il produit un code efficace - à moins qu'il n'y ait un cache d'instructions
la pression, une situation fréquente dans les logiciels modernes !

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment-318242016 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AT4HVb2SPMpe5dlEDUQeadIRKPaB74zoks5sR_jSgaJpZM4IG-xv
.

Il ne fait aucun doute que la génération de code n'est pas une VRAIE solution, même si elle est accompagnée d'un support linguistique pour donner l'apparence et la convivialité comme une "partie du langage"

Mon point était que c'était TRÈS rentable.

Au fait, si vous regardez certains des substituts de génération de code, vous pouvez facilement voir comment ils auraient pu être beaucoup plus lisibles, plus rapides et manquer de concepts erronés (par exemple, itération sur des tableaux de pointeurs vs valeurs) si le langage leur avait donné de meilleurs outils pour ça.

Et c'est peut-être une meilleure solution à court terme, qui ne ressemblerait pas à un patch :
avant de penser au "meilleur support générique qui sera également idiomatique" (je pense que certaines implémentations ci-dessus prendraient des années pour accomplir une intégration complète), implémentez des ensembles de fonctions "en langage" qui sont nécessaires de toute façon (comme un build in structure copie profonde) rendrait ces solutions de génération de code beaucoup plus utilisables.

Après avoir lu les propositions génériques de @bcmills et @ianlancetaylor , j'ai fait les observations suivantes :

Fonctions de compilation et types de première classe

J'aime l'idée de l'évaluation au moment de la compilation, mais je ne vois pas l'avantage de la limiter aux fonctions pures. Cette proposition introduit la fonction intégrée gotype , mais limite son utilisation aux fonctions const et à tous les types de données définis dans la portée de la fonction. Du point de vue d'un utilisateur de bibliothèque, l'instanciation est limitée aux fonctions constructeur comme "New", et conduit à des signatures de fonction comme celle-ci :

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

Le type de retour ici ne peut pas être séparé en un type de fonction car nous sommes limités aux fonctions pures. De plus, la signature définit deux nouveaux "types" dans la signature elle-même (K et V), ce qui signifie que pour analyser un seul paramètre, nous devons analyser toute la liste des paramètres. C'est bien pour un compilateur, mais je me demande si cela ajoute de la complexité à l'API publique d'un package.

Paramètres de type dans Go

Les types paramétrés permettent la plupart des cas d'utilisation de la programmation générique, par exemple la possibilité de définir des structures de données génériques et des opérations sur différents types de données. La proposition répertorie de manière exhaustive les améliorations du vérificateur de type qui seraient nécessaires pour produire de meilleures erreurs de compilation, des temps de compilation plus rapides et des fichiers binaires plus petits.

Sous la section "Type Checker", la proposition répertorie également certaines restrictions de type utiles pour accélérer le processus, comme "Indexable", "Comparable", "Callable", "Composite", etc. Ce que je ne comprends pas, c'est pourquoi ne pas permettre à l'utilisateur de spécifier ses propres restrictions de type ? La proposition stipule que

Il n'y a aucune restriction sur la façon dont les types paramétrés peuvent être utilisés dans une fonction paramétrée.

Cependant, si les identifiants avaient plus de contraintes liées à eux, cela n'aurait-il pas pour effet d'aider le compilateur ? Envisager:

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.

Séparer les contraintes de type des paramètres de type et autoriser les contraintes définies par l'utilisateur pourrait également améliorer la lisibilité, rendant les packages génériques plus faciles à comprendre. Fait intéressant, les défauts énumérés à la fin de la proposition concernant la complexité des règles de déduction de type pourraient en fait être atténués si ces règles sont explicitement définies par l'utilisateur.

@ smasher164

J'aime l'idée de l'évaluation au moment de la compilation, mais je ne vois pas l'avantage de la limiter aux fonctions pures.

L'avantage est qu'il permet une compilation séparée. Si une fonction au moment de la compilation peut modifier l'état global, le compilateur doit soit disposer de cet état, soit journaliser les modifications de manière à ce que l'éditeur de liens puisse les séquencer au moment de la liaison. Si une fonction de compilation peut modifier l'état local, nous aurions besoin d'un moyen de savoir quel état est local ou global. Les deux ajoutent de la complexité, et il n'est pas évident que l'un ou l'autre fournirait suffisamment d'avantages pour le compenser.

@ smasher164

Ce que je ne comprends pas, c'est pourquoi ne pas autoriser l'utilisateur à spécifier ses propres restrictions de type ?

Les restrictions de type dans cette proposition correspondent à des opérations dans la syntaxe du langage. Cela réduit la surface des nouvelles fonctionnalités : il n'est pas nécessaire de spécifier une syntaxe supplémentaire pour les types contraignants, car toutes les contraintes syntaxiques peuvent être déduites de l'utilisation.

si les identifiants avaient plus de contraintes liées à eux, cela n'aurait-il pas pour effet d'aider le compilateur ?

Le langage doit être conçu pour ses utilisateurs, pas pour les compilateurs-écrivains.

il n'est pas nécessaire de spécifier une syntaxe supplémentaire pour les types contraignants car toutes les contraintes syntaxiques peuvent être déduites de l'utilisation.

C'est la voie empruntée par C++. Elle nécessite une analyse globale du programme pour identifier les usages pertinents. Le code ne peut pas être raisonné par les programmeurs de manière modulaire, et les messages d'erreur sont verbeux et incompréhensibles.

Il peut être si facile et léger de spécifier les opérations nécessaires. Voir CLU (1977) pour un exemple.

@andrewcmyers

Elle nécessite une analyse globale du programme pour identifier les usages pertinents. Le code ne peut pas être raisonné par les programmeurs de manière modulaire,

Cela utilise une définition particulière de "modulaire", qui, à mon avis, n'est pas aussi universelle que vous semblez le supposer. Selon la proposition de 2013, chaque fonction ou type aurait un ensemble non ambigu de contraintes déduites de bas en haut à partir de packages importés, exactement de la même manière que le temps d'exécution (et les contraintes d'exécution) des fonctions non paramétriques sont dérivés de bas en haut. des chaînes d'appel aujourd'hui.

Vous pourriez probablement interroger les contraintes déduites à l'aide guru ou d'un outil similaire, et il pourrait répondre à ces requêtes en utilisant des informations locales à partir des métadonnées du package exporté.

et les messages d'erreur sont verbeux et incompréhensibles.

Nous avons quelques exemples (GCC et MSVC) démontrant que les messages d'erreur générés naïvement sont incompréhensibles. Je pense qu'il est exagéré de supposer que les messages d'erreur pour les contraintes implicites sont intrinsèquement mauvais.

Je pense que le plus gros inconvénient des contraintes inférées est qu'elles facilitent l'utilisation d'un type d'une manière qui introduit une contrainte sans la comprendre pleinement. Dans le meilleur des cas, cela signifie simplement que vos utilisateurs peuvent rencontrer des échecs de compilation inattendus, mais dans le pire des cas, cela signifie que vous pouvez casser le package pour les consommateurs en introduisant une nouvelle contrainte par inadvertance. Des contraintes explicitement spécifiées éviteraient cela.

Personnellement, je ne pense pas non plus que les contraintes explicites soient en décalage avec l'approche Go existante, car les interfaces sont des contraintes de type d'exécution explicites, bien qu'elles aient une expressivité limitée.

Nous avons quelques exemples (GCC et MSVC) démontrant que les messages d'erreur générés naïvement sont incompréhensibles. Je pense qu'il est exagéré de supposer que les messages d'erreur pour les contraintes implicites sont intrinsèquement mauvais.

La liste des compilateurs sur lesquels l'inférence de type non locale - ce que vous proposez - entraîne de mauvais messages d'erreur est un peu plus longue que cela. Cela inclut SML, OCaml et GHC, où beaucoup d'efforts ont déjà été consacrés à l'amélioration de leurs messages d'erreur et où il existe au moins une structure de module explicite aidant. Vous pourrez peut-être faire mieux, et si vous trouvez un algorithme pour de bons messages d'erreur avec le schéma que vous proposez, vous aurez une belle publication. Comme point de départ vers cet algorithme, vous trouverez peut-être utiles nos articles POPL 2014 et PLDI 2015 sur la localisation des erreurs. Ils sont plus ou moins à la pointe de la technologie.

car toutes les contraintes syntaxiques peuvent être déduites de l'usage.

Cela ne limite-t-il pas l'étendue des programmes génériques vérifiables par type ? Par exemple, notez que la proposition type-params ne spécifie pas de contrainte "Iterable". Dans le langage actuel, cela correspondrait soit à une tranche, soit à un canal, mais un type composite (disons une liste chaînée) ne satisferait pas nécessairement à ces exigences. Définir une interface comme

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

aide le cas de la liste chaînée, mais maintenant les types de tranche et de canal intégrés doivent être étendus pour satisfaire cette interface.

Une contrainte qui dit "J'accepte l'ensemble de tous les types qui sont des itérables, des tranches ou des canaux" semble être une situation gagnant-gagnant-gagnant pour l'utilisateur, l'auteur du package et l'implémenteur du compilateur. Le point que j'essaie de faire valoir est que les contraintes sont un sur-ensemble de programmes syntaxiquement valides, et certains peuvent ne pas avoir de sens du point de vue du langage, mais uniquement du point de vue de l'API.

Le langage doit être conçu pour ses utilisateurs, pas pour les compilateurs-écrivains.

Je suis d'accord, mais j'aurais peut-être dû le formuler différemment. L'amélioration de l'efficacité du compilateur pourrait être un effet secondaire des contraintes définies par l'utilisateur. Le principal avantage serait la lisibilité, car l'utilisateur a de toute façon une meilleure idée du comportement de son API que le compilateur. Le compromis ici est que les programmes génériques devraient être légèrement plus explicites sur ce qu'ils acceptent.

Et si au lieu de

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

nous avons séparé la notion d'"interfaces" de celle de "contraintes". Ensuite, nous pourrions avoir

type T generic

type Iterable class {
    Next() T
}

où "classe" signifie une classe de type de style Haskell, pas une classe de style Java.

Avoir des "classes de types" séparées des "interfaces" pourrait aider à clarifier une partie de la non-orthogonalité des deux idées. Alors Sortable (en ignorant sort.Interface) pourrait ressembler à :

type T generic

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

type Sortable class {
    Next() Comparable
}

Voici quelques commentaires sur la section "Classes et concepts de types" dans Genus par @andrewcmyers et son applicabilité à Go.

Cette section aborde les limitations des classes de types et des concepts, indiquant

premièrement, la satisfaction des contraintes doit être observée de manière unique

Je ne suis pas sûr de comprendre cette limitation. Lier une contrainte à des identifiants séparés ne l'empêcherait-il pas d'être unique pour un type donné ? Il me semble que la clause "where" dans Genus construit essentiellement un type/contrainte à partir d'une contrainte donnée, mais cela semble analogue à l'instanciation d'une variable à partir d'un type donné. Une contrainte ressemble ainsi à un kind .

Voici une simplification spectaculaire des définitions de contraintes, adaptée à 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.

Ainsi, une déclaration de carte apparaîtrait comme :

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

où dans Genus, cela pourrait ressembler à:

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

et dans la proposition Type-Params existante, cela ressemblerait à :

type Map[K,V] struct {
}

Je pense que nous pouvons tous convenir que permettre aux contraintes de tirer parti du système de type existant peut à la fois supprimer le chevauchement entre les fonctionnalités du langage et faciliter la compréhension des nouvelles.

et deuxièmement, leurs modèles définissent comment adapter un seul type, alors que dans un langage avec sous-typage, chaque type adapté représente en général tous ses sous-types.

Cette limitation semble moins pertinente pour Go puisque le langage a déjà de bonnes règles de conversion entre les types nommés/non nommés et les interfaces qui se chevauchent.

Les exemples donnés proposent des modèles comme solution, ce qui semble être une fonctionnalité utile mais pas nécessaire pour Go. Si une bibliothèque s'attend à ce qu'un type implémente http.Handler par exemple, et que l'utilisateur souhaite des comportements différents selon le contexte, écrire des adaptateurs est simple :

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

En fait, c'est ce que fait la bibliothèque standard .

@ smasher164

premièrement, la satisfaction des contraintes doit être observée de manière unique
Je ne suis pas sûr de comprendre cette limitation. Est-ce que lier une contrainte à des identifiants séparés ne l'empêcherait pas d'être unique pour un type donné ?

L'idée est que dans Genus vous pouvez satisfaire la même contrainte avec le même type de plusieurs manières, contrairement à Haskell. Par exemple, si vous avez un HashSet[T] , vous pouvez écrire HashSet[String] pour hacher les chaînes de la manière habituelle mais HashSet[String with CaseInsens] pour hacher et comparer les chaînes avec le CaseInsens modèle, qui traite vraisemblablement les chaînes de manière insensible à la casse. Le genre distingue en fait ces deux types ; cela pourrait être exagéré pour Go. Même si le système de type n'en garde pas trace, il semble toujours important de pouvoir remplacer les opérations par défaut fournies par un type.

kind Any interface{} // accepte tout type qui satisfait interface{}.
type T Any // Déclare un type Any kind. Le lie également à un identifiant.
kind Eq T == T // accepte tout type pour lequel l'égalité est définie.
type Map[K Eq, V Any] struct { ...
}

L'équivalent moral de ceci dans Genus serait :

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

Dans Familia nous écrirons simplement :

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

Edit : rétracter ceci en faveur d'une solution basée sur la réflexion comme décrit dans # 4146 Une solution basée sur les génériques comme je l'ai décrite ci-dessous augmente de manière linéaire le nombre de compositions. Alors qu'une solution basée sur la réflexion aura toujours un handicap de performance, elle peut s'optimiser au moment de l'exécution afin que le handicap soit constant quel que soit le nombre de compositions.

Il ne s'agit pas d'une proposition, mais d'un cas d'utilisation potentiel à prendre en compte lors de la conception d'une proposition.

Deux choses sont communes dans le code Go aujourd'hui

• envelopper une valeur d'interface pour fournir des fonctionnalités supplémentaires (envelopper un http.ResponseWriter pour un framework)
• avoir des méthodes optionnelles qui ont parfois des valeurs d'interface (comme Temporary() bool sur net.Error )

Ce sont à la fois bons et utiles, mais ils ne se mélangent pas. Une fois que vous avez encapsulé une interface, vous avez perdu la possibilité d'accéder à toutes les méthodes non définies sur le type d'encapsulation. c'est-à-dire étant donné

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

Si vous encapsulez une erreur dans cette structure, vous masquez toutes les méthodes supplémentaires sur l'erreur d'origine.

Si vous n'encapsulez pas l'erreur dans la structure, vous ne pouvez pas fournir le contexte supplémentaire.

Disons que la proposition générique acceptée vous permet de définir quelque chose comme ce qui suit (syntaxe arbitraire que j'ai essayé de rendre intentionnellement laide pour que personne ne se concentre dessus)

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

En tirant parti de l'intégration, nous pourrions intégrer n'importe quel type concret satisfaisant l'interface d'erreur et à la fois l'envelopper et avoir accès à ses autres méthodes. Malheureusement, cela ne nous amène qu'à mi-chemin.

Ce dont nous avons vraiment besoin ici, c'est de prendre une valeur arbitraire de l'interface d'erreur et d'intégrer son type dynamique.

Cela soulève immédiatement deux préoccupations

• le type devrait être créé au moment de l'exécution (probablement nécessaire par reflect de toute façon)
• la création de type devrait paniquer si la valeur d'erreur est nulle

Si ceux-ci ne vous ont pas aigri, vous avez également besoin d'un mécanisme pour "sauter" l'interface vers son type dynamique, soit par une annotation dans la liste des paramètres génériques pour dire "toujours instancier sur le type dynamique des valeurs d'interface " ou par une fonction magique qui ne peut être appelée que lors de l'instanciation de type pour déballer l'interface afin que son type et sa valeur puissent être correctement épissés.

Sans cela, vous instanciez simplement MyError sur le type d'erreur lui-même et non sur le type dynamique de l'interface.

Disons que nous avons une fonction magique unbox à extraire et (d'une manière ou d'une autre) appliquer les informations :

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

Supposons maintenant que nous ayons une erreur non nulle, err , dont le type dynamique est *net.DNSError . Ensuite ceci

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

imprimerait true . Mais si le type dynamique de err avait été *os.PathError , il aurait imprimé false.

J'espère que la sémantique proposée est claire compte tenu de la syntaxe obtuse utilisée dans la démonstration.

J'espère également qu'il existe un meilleur moyen de résoudre ce problème avec moins de mécanisme et de cérémonie, mais je pense que ce qui précède pourrait fonctionner.

@jimmyfrasche Si je comprends ce que vous voulez, c'est un mécanisme d'adaptation sans wrapper. Vous voulez pouvoir étendre l'ensemble des opérations qu'un type offre sans l'envelopper dans un autre objet qui masque l'original. C'est une fonctionnalité offerte par Genus.

@andrewcmyers non.

Struct's in Go permet l'intégration. Si vous ajoutez un champ sans nom mais avec un type à une structure, il fait deux choses : il crée un champ avec le même nom que le type et il permet une distribution transparente à toutes les méthodes de ce type. Cela ressemble terriblement à un héritage, mais ce n'en est pas un. Si vous aviez un type T qui avait une méthode Foo() alors les éléments suivants sont équivalents

type S struct {
  T
}

et

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

(lorsque Foo est appelé, son "ceci" est toujours de type T).

Vous pouvez également intégrer des interfaces dans des structures. Cela donne à la structure toutes les méthodes du contrat de l'interface (bien que vous deviez attribuer une valeur dynamique au champ implicite ou cela provoquera une panique avec l'équivalent d'une exception de pointeur nul)

Go a des interfaces qui définissent un contrat en termes de méthodes d'un type. Une valeur de n'importe quel type qui satisfait le contrat peut être encadrée dans une valeur de cette interface. Une valeur d'une interface est un pointeur vers le manifeste de type interne (type dynamique) et un pointeur vers une valeur de ce type dynamique (valeur dynamique). Vous pouvez faire des assertions de type sur une valeur d'interface pour (a) obtenir la valeur dynamique si vous affirmez à son type non-interface ou (b) obtenir une nouvelle valeur d'interface si vous affirmez à une interface différente que la valeur dynamique satisfait également. Il est courant d'utiliser ce dernier pour "tester les fonctionnalités" d'un objet pour voir s'il prend en charge les méthodes facultatives. Pour réutiliser un exemple précédent, certaines erreurs ont une méthode "Temporary() bool" afin que vous puissiez voir si une erreur est temporaire avec :

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

Il est également courant d'envelopper un type dans un autre type pour fournir des fonctionnalités supplémentaires. Cela fonctionne bien avec les types non-interface. Lorsque vous encapsulez une interface, vous masquez également les méthodes que vous ne connaissez pas et que vous ne pouvez pas les récupérer avec des assertions de type "test de fonctionnalité": le type encapsulé n'expose que les méthodes requises de l'interface même si elle a des méthodes optionnelles . Envisager:

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

type I interface {
  Foo()
}

type B struct {
  I
}

var i I = B{A{}}

Vous ne pouvez pas appeler Bar sur i ou même savoir qu'il existe à moins que vous ne sachiez que le type dynamique de i est un B afin que vous puissiez le déballer et accéder au champ I pour taper assert dessus .

Cela pose de réels problèmes, en particulier avec les interfaces courantes telles que error ou Reader.

S'il existait un moyen d'extraire le type et la valeur dynamiques d'une interface (d'une manière sûre et contrôlée), vous pourriez paramétrer un nouveau type avec cela, définir le champ intégré sur la valeur et renvoyer une nouvelle interface. Ensuite, vous obtenez une valeur qui satisfait l'interface d'origine, possède toutes les fonctionnalités améliorées que vous souhaitez ajouter, mais le reste des méthodes du type dynamique d'origine sont toujours là pour être testées.

@jimmyfrasche En effet. Ce que Genus vous permet de faire, c'est d'utiliser un type pour satisfaire un contrat "d'interface" sans le boxer. La valeur a toujours son type d'origine et ses opérations d'origine. De plus, le programme peut spécifier les opérations que le type doit utiliser pour satisfaire le contrat -- par défaut, ce sont les opérations que le type fournit, mais le programme peut en fournir de nouvelles si le type n'a pas les opérations nécessaires. Il peut également remplacer les opérations que le type utiliserait.

@jimmyfrasche @andrewcmyers Pour ce cas d'utilisation, voir aussi https://github.com/golang/go/issues/4146#issuecomment -318200547.

@jimmyfrasche Pour moi, il semble que le problème clé ici soit d'obtenir le type/valeur dynamique d'une variable. Mis à part l'intégration, un exemple simplifié serait

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

La valeur affectée à e doit avoir un type dynamique (ou concret) de quelque chose comme *net.DNSError , qui implémente error . Voici quelques façons possibles dont un futur changement de langue pourrait résoudre ce problème :

1. Avoir une fonction magique semblable unbox qui découvre la valeur dynamique d'une variable. Cela s'applique à tout type qui n'est pas concret, par exemple les syndicats.
2. Si le changement de langage prend en charge les variables de type, fournissez un moyen d'obtenir le type dynamique de la variable. Avec les informations de type, nous pouvons écrire nous-mêmes la fonction unbox . Par example,

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

wrap peut être écrit de la même manière qu'avant, ou comme

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

1. Si le changement de langue prend en charge les contraintes de type, voici une idée alternative :

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

Dans cet exemple, nous acceptons une valeur de n'importe quel type qui implémente error. Tout utilisateur de wrap qui attend un error en recevra un. Cependant, le type du e à l'intérieur MyError est le même que celui du err qui est passé, qui n'est pas limité à un type d'interface. Si on voulait le même comportement que 2,

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

Puisque personne d'autre ne semble l'avoir fait, je voudrais souligner les "rapports d'expérience" très évidents pour les génériques, comme demandé par https://blog.golang.org/toward-go2.

Le premier est le type intégré map :

m := make(map[string]string)

Le suivant est le type intégré chan :

c := make(chan bool)

Enfin, la bibliothèque standard est truffée d'alternatives interface{} où les génériques fonctionneraient de manière plus sûre :

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

Il y en a peut-être d'autres qui me manquent. Le fait est que chacun des éléments ci-dessus est là où je m'attendrais à ce que les génériques soient utiles.

(Remarque : je n'inclus pas sort.Sort ici car c'est un excellent exemple de la façon dont les interfaces peuvent être utilisées à la place des génériques.)

http://www.yinwang.org/blog-cn/2014/04/18/golang
Je pense que le générique est important. Sinon, ne peut pas gérer des types similaires. Parfois, l'interface ne peut pas résoudre le problème.

La syntaxe simple et le système de type sont les avantages importants de Go. Si vous ajoutez des génériques, le langage deviendra un vilain gâchis comme Scala ou Haskell. De plus, cette fonctionnalité attirera des fanboys pseudo-académiques, qui finiront par transformer les valeurs communautaires de "Faisons-le" à "Parlons de la théorie et des mathématiques de CS". Évitez les génériques, c'est un chemin vers l'abîme.

@bxqgit s'il vous plaît gardez cela civil. Inutile d'insulter qui que ce soit.

Quant à ce que l'avenir apportera, nous verrons, mais je sais que pendant 98% de mon temps, je n'ai pas besoin de génériques, chaque fois que j'en ai besoin, j'aimerais pouvoir les utiliser. Comment sont-ils utilisés et comment sont-ils utilisés à tort est une discussion différente. L'éducation des utilisateurs devrait faire partie du processus.

@bxqgit
Il y a des situations dans lesquelles des génériques sont nécessaires, comme des structures de données génériques (Trees, Stacks, Queues , ...) ou des fonctions génériques (Map, Filter, Reduce, ...) et ces choses sont inévitables, en utilisant des interfaces au lieu de génériques dans ces situations ajoutent simplement une énorme complexité à la fois pour l'écrivain de code et le lecteur de code et cela a également un effet néfaste sur l'efficacité du code au moment de l'exécution, il devrait donc être beaucoup plus rationnel d'ajouter aux génériques du langage que d'essayer d'utiliser des interfaces et de réfléchir pour écrire complexe et code inefficace.

@bxqgit L'ajout de génériques n'ajoute pas nécessairement de la complexité au langage, cela peut également être réalisé avec une syntaxe simple. Avec les génériques, vous ajoutez une contrainte de type de temps de compilation variable qui est très utile avec les structures de données, comme l'a dit @riwogo .

Le système d'interface actuel dans go est très utile, néanmoins très mauvais lorsque vous avez besoin, par exemple, d'une implémentation générale de list, qui avec les interfaces nécessite une contrainte de type de temps d'exécution, néanmoins si vous ajoutez des génériques, le type générique peut être substitué dans temps de compilation avec le type réel, rendant la contrainte inutile.

De plus, rappelez-vous, les personnes derrière vont, développent le langage en utilisant ce que vous appelez "la théorie et les mathématiques de l'informatique", et sont également les personnes qui "font cela".

De plus, rappelez-vous, les personnes derrière vont, développent le langage en utilisant ce que vous appelez "la théorie et les mathématiques de l'informatique", et sont également les personnes qui "font cela".

Personnellement, je ne vois pas beaucoup de théorie CS et de mathématiques dans la conception du langage Go. C'est une langue assez primitive, ce qui est bien à mon avis. De plus, les personnes dont vous parlez ont décidé d'éviter les génériques et ont fait avancer les choses. Si ça marche bien, pourquoi changer quoi que ce soit ? En règle générale, je pense que l'évolution et l'extension constantes de la syntaxe du langage sont une mauvaise pratique. Cela ne fait qu'ajouter de la complexité qui conduit au chaos de Haskell et Scala.

Le modèle est compliqué mais les génériques sont simples

Regardez les fonctions SortInts, SortFloats, SortStrings dans le package de tri. Ou SearchInts, SearchFloats, SearchStrings. Ou les méthodes Len, Less et Swap de byName dans le package io/ioutil. Copie passe-partout pure.

Les fonctions de copie et d'ajout existent car elles rendent les tranches beaucoup plus utiles. Les génériques signifieraient que ces fonctions sont inutiles. Les génériques permettraient d'écrire des fonctions similaires pour les cartes et les canaux, sans parler des types de données créés par l'utilisateur. Certes, les tranches sont le type de données composite le plus important, et c'est pourquoi ces fonctions étaient nécessaires, mais d'autres types de données sont toujours utiles.

Mon vote est non aux applications génériques généralisées, oui à des fonctions génériques plus intégrées telles que append et copy qui fonctionnent sur plusieurs types de base. Peut-être que sort et search pourraient être ajoutés pour les types de collection ?

Pour mes applications, le seul type manquant est un ensemble non ordonné (https://github.com/golang/go/issues/7088), j'aimerais cela comme un type intégré afin qu'il obtienne le typage générique comme slice et map . Mettez le travail dans le compilateur (analyse comparative pour chaque type de base et un ensemble sélectionné de types struct puis ajustement pour de meilleures performances) et gardez les annotations supplémentaires hors du code de l'application.

smap intégré au lieu de sync.Map aussi s'il vous plaît. D'après mon expérience, l'utilisation interface{} pour la sécurité du type d'exécution est un défaut de conception. La vérification de type au moment de la compilation est une raison majeure d'utiliser Go.

@pciet

D'après mon expérience, l'utilisation de l'interface{} pour la sécurité du type d'exécution est un défaut de conception.

Pouvez-vous simplement écrire un petit emballage (de type sûr) ?
https://play.golang.org/p/tG6hd-j5yx

@pierrre Ce wrapper vaut mieux qu'un reflect.TypeOf(item).AssignableTo(type) . Mais écrire votre propre type avec map + sync.Mutex ou sync.RWMutex est la même complexité sans l'assertion de type que requiert sync.Map .

Mon utilisation de la carte synchronisée a été pour les cartes globales de mutex avec un var myMapLock = sync.RWMutex{} à côté au lieu de créer un type. Cela pourrait être plus propre. Un type intégré générique me semble juste mais demande un travail que je ne peux pas faire, et je préfère mon approche à l'assertion de type.

Je soupçonne que la réaction viscérale négative aux génériques que de nombreux programmeurs Go semblent avoir survient parce que leur principale exposition aux génériques s'est faite via des modèles C++. C'est malheureux car C++ s'est tragiquement trompé sur les génériques dès le premier jour et a aggravé l'erreur depuis. Les génériques pour Go pourraient être beaucoup plus simples et moins sujets aux erreurs.

Il serait décevant de voir Go devenir de plus en plus complexe en ajoutant des types paramétrés intégrés. Il serait préférable d'ajouter simplement le support du langage pour que les programmeurs écrivent leurs propres types paramétrés. Ensuite, les types spéciaux pourraient simplement être fournis en tant que bibliothèques plutôt que d'encombrer le langage de base.

@andrewcmyers "Les génériques pour Go pourraient être beaucoup plus simples et moins sujets aux erreurs." --- comme les génériques en C#.

Il est décevant de voir Go devenir de plus en plus complexe en ajoutant des types paramétrés intégrés.

Malgré les spéculations dans ce numéro, je pense que cela est extrêmement peu probable.

L'exposant de la mesure de complexité des types paramétrés est la variance.
Les types de Go (à l'exception des interfaces) sont invariants et cela peut et doit être
gardé la règle.

Une implémentation mécanique des génériques "copier-coller" assistée par un compilateur
résoudrait 99 % du problème d'une manière fidèle à la stratégie sous-jacente de Go
principes de superficialité et de non-surprise.

Soit dit en passant, cela et des dizaines d'autres idées viables ont été discutées
avant et certains ont même abouti à de bonnes approches réalisables. À ceci
point, je suis à la limite du papier d'aluminium sur la façon dont ils ont tous disparu
silencieusement dans le vide.

Le 28 novembre 2017 à 23h54, "Andrew Myers" [email protected] a écrit :

Je soupçonne que la réaction viscérale négative aux génériques que beaucoup de Go
les programmeurs semblent avoir surgi parce que leur exposition principale aux génériques était
via des modèles C++. C'est malheureux car C++ a tragiquement obtenu des génériques
tort dès le premier jour et a aggravé l'erreur depuis. Génériques pour
Go pourrait être beaucoup plus simple et moins sujet aux erreurs.

Il est décevant de voir le Go devenir de plus en plus complexe en ajoutant
types paramétrés intégrés. Il serait préférable d'ajouter simplement la langue
prise en charge pour les programmeurs d'écrire leurs propres types paramétrés. Puis le
les types spéciaux pourraient simplement être fournis sous forme de bibliothèques plutôt que d'encombrer
la langue de base.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment-347691444 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AJZ_jPsQd2qBbn9NI1wZeT-O2JpyraTMks5s7I81gaJpZM4IG-xv
.

Oui, vous pouvez avoir des génériques sans modèles. Les modèles sont une forme de polymorphisme paramétrique avancé principalement pour les installations de métaprogrammation.

@ianlancetaylor Rust permet à un programme d'implémenter un trait T sur un type existant Q , à condition que leur caisse définisse T ou Q .

Juste une pensée : je me demande si Simon Peyton Jones (oui, de la renommée de Haskell) et/ou les développeurs de Rust pourraient être en mesure d'aider. Rust et Haskell ont probablement les deux systèmes de type les plus avancés de tous les langages de production, et Go devrait apprendre d'eux.

Il y a aussi Phillip Wadler , qui a travaillé sur Generic Java , qui a finalement conduit à l'implémentation des génériques dont Java dispose aujourd'hui.

@tarcieri Je ne pense pas que les génériques de Java soient très bons, mais ils ont fait leurs preuves.

@DemiMarie Nous avons eu Andrew Myers ici, heureusement.

Sur la base de mon expérience personnelle, je pense que les personnes qui connaissent bien les différentes langues et les différents systèmes de types peuvent être très utiles pour examiner les idées. Mais pour produire les idées en premier lieu, ce dont nous avons besoin, ce sont des personnes qui connaissent très bien Go, comment cela fonctionne aujourd'hui et comment cela peut raisonnablement fonctionner à l'avenir. Go est conçu pour être, entre autres, un langage simple. Il est peu probable que l'importation d'idées à partir de langages tels que Haskell ou Rust, qui sont nettement plus compliqués que Go, soit un bon choix. Et en général, les idées de personnes qui n'ont pas encore écrit une quantité raisonnable de code Go sont peu susceptibles de convenir ; non pas que les idées soient mauvaises en tant que telles, mais simplement qu'elles ne cadrent pas bien avec le reste du langage.

Par exemple, il est important de comprendre que Go a déjà une prise en charge partielle de la programmation générique à l'aide de types d'interface et a déjà une prise en charge (presque) complète à l'aide du package reflect. Bien que ces deux approches de la programmation générique ne soient pas satisfaisantes pour diverses raisons, toute proposition de génériques en Go doit bien interagir avec elles tout en remédiant à leurs lacunes.

En fait, pendant que je suis ici, il y a quelque temps, j'ai pensé à la programmation générique avec des interfaces pendant un certain temps et j'ai trouvé trois raisons pour lesquelles cela n'était pas satisfaisant.

1. Les interfaces exigent que toutes les opérations soient exprimées sous forme de méthodes. Cela rend difficile l'écriture d'une interface pour les types intégrés, tels que les types de canal. Tous les types de canaux prennent en charge l'opérateur <- pour les opérations d'envoi et de réception, et il est assez facile d'écrire une interface avec les méthodes Send et Receive , mais pour attribuer une valeur de canal pour ce type d'interface, vous devez écrire les méthodes passe-partout Send et Receive . Ces méthodes passe-partout auront exactement la même apparence pour chaque type de canal différent, ce qui est fastidieux.

2. Les interfaces sont typées dynamiquement, et ainsi les erreurs combinant différentes valeurs typées statiquement ne sont détectées qu'au moment de l'exécution, pas au moment de la compilation. Par exemple, une fonction Merge qui fusionne deux canaux en un seul canal en utilisant leurs méthodes Send et Receive exigera que les deux canaux aient des éléments du même type, mais que la vérification ne peut être effectuée qu'au moment de l'exécution.

3. Les interfaces sont toujours encadrées. Par exemple, il n'y a aucun moyen d'utiliser des interfaces pour agréger une paire d'autres types sans mettre ces autres types dans des valeurs d'interface, ce qui nécessite des allocations de mémoire supplémentaires et la recherche de pointeurs.

Je suis heureux de kibitz sur les propositions de génériques pour Go. La quantité croissante de recherches sur les génériques à Cornell ces derniers temps, apparemment pertinente pour ce qui pourrait être fait avec Go, est peut-être également intéressante :

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)

Dans l'analyse comparative de la carte par rapport à la tranche pour un type d'ensemble non ordonné, j'ai écrit des tests unitaires séparés pour chacun, mais avec les types d'interface, je peux combiner ces deux listes de tests en une seule :

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
}

Test de suppression d'un élément :

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

De cette façon, je peux regrouper mes cas précédemment séparés en une seule tranche de cas sans aucun problème :

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

Pour chaque type de béton, j'ai dû définir les méthodes d'interface. Par example:

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

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

Ces tests génériques pourraient utiliser une vérification de type proposée au moment de la compilation :

type Item generic {
    Equal(Item) bool
}

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

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

En y réfléchissant davantage, il ne semble pas qu'une vérification de type au moment de la compilation soit possible pour un tel test, car vous devrez exécuter le programme pour savoir si un type est passé à la méthode d'interface correspondante.

Alors qu'en est-il d'un type "générique" qui est une interface et qui a une assertion de type invisible ajoutée par le compilateur lorsqu'il est utilisé concrètement ?

@andrewcmyers L'article "Familia" était intéressant (et bien au-dessus de ma tête). Une notion clé était l'héritage. Comment les concepts changeraient-ils pour un langage comme Go qui repose sur la composition au lieu de l'héritage ?

Merci. La partie héritage ne s'applique pas à Go - si vous n'êtes intéressé que par les génériques pour Go, vous pouvez arrêter de lire après la section 4 de l'article. La principale chose à propos de cet article qui est pertinente pour Go est qu'il montre comment utiliser les interfaces à la fois dans la façon dont elles sont utilisées pour Go maintenant et en tant que contraintes sur les types pour les abstractions génériques. Ce qui signifie que vous bénéficiez de la puissance des classes de type Haskell sans ajouter une toute nouvelle construction au langage.

@andrewcmyers Pouvez-vous donner un exemple de ce à quoi cela ressemblerait dans Go ?

La principale chose à propos de cet article qui est pertinente pour Go est qu'il montre comment utiliser les interfaces à la fois dans la façon dont elles sont utilisées pour Go maintenant et en tant que contraintes sur les types pour les abstractions génériques.

Ma compréhension est que l'interface Go définit une contrainte sur un type (par exemple "ce type peut être comparé pour l'égalité en utilisant 'l'interface de type Comparable' car il satisfait d'avoir une méthode Eq"). Je ne suis pas sûr de comprendre ce que vous entendez par une contrainte de type.

Je ne connais pas Haskell, mais la lecture d'un aperçu rapide me fait deviner que les types qui correspondent à une interface Go s'intégreraient dans cette classe de types. Pouvez-vous expliquer ce qui est différent dans les classes de type Haskell ?

Une comparaison concrète entre Familia et Go serait intéressante. Merci d'avoir partagé votre papier.

Les interfaces Go peuvent être considérées comme décrivant une contrainte sur les types, via le sous-typage structurel. Cependant, cette contrainte de type, telle quelle, n'est pas suffisamment expressive pour capturer les contraintes souhaitées pour la programmation générique. Par exemple, vous ne pouvez pas exprimer la contrainte de type nommée Eq dans l'article Familia.

Quelques réflexions sur la motivation pour des installations de programmation plus génériques en Go :

Il y a donc ma liste de tests génériques qui n'a pas vraiment besoin d'être ajouté à la langue. À mon avis, le type générique que j'ai proposé ne satisfait pas l'objectif Go de compréhension directe, il n'a pas grand-chose à voir avec le terme de programmation généralement accepté, et faire l'affirmation de type n'était pas moche car une panique sur l'échec est amende. Je suis déjà satisfait des fonctionnalités de programmation génériques de Go pour mon besoin.

Mais sync.Map est un cas d'utilisation différent. Il y a un besoin dans la bibliothèque standard pour une implémentation de carte synchronisée générique mature au-delà d'une simple structure avec une carte et un mutex. Pour la gestion des types, nous pouvons l'envelopper avec un autre type qui définit un type non-interface{} et effectue une assertion de type, ou nous pouvons ajouter une vérification de réflexion en interne afin que les éléments qui suivent le premier doivent correspondre au même type. Les deux ont des vérifications d'exécution, l'emballage nécessite de réécrire chaque méthode pour chaque type d'utilisation, mais il ajoute une vérification de type au moment de la compilation pour l'entrée et masque l'assertion de type de sortie, et avec la vérification interne, nous devons quand même faire une assertion de type de sortie. Dans tous les cas, nous effectuons des conversions d'interface sans aucune utilisation réelle des interfaces ; interface{} est un hack du langage et ne sera pas clair pour les nouveaux programmeurs Go. Bien que json.Marshal soit une bonne conception à mon avis (y compris les balises de structure laides mais sensibles).

J'ajouterai que puisque sync.Map est dans la bibliothèque standard, idéalement, il devrait échanger l'implémentation pour les cas d'utilisation mesurés où la structure simple est plus performante. La carte non synchronisée est un premier piège courant dans la programmation simultanée Go et un correctif de bibliothèque standard devrait fonctionner.

La carte régulière n'a qu'une vérification de type au moment de la compilation et ne nécessite aucun de ces échafaudages. Je soutiens que sync.Map devrait être le même ou ne devrait pas être dans la bibliothèque standard pour Go 2.

J'ai proposé d'ajouter sync.Map à la liste des types intégrés et de faire de même pour les futurs besoins similaires. Mais ma compréhension est de donner aux programmeurs Go un moyen de le faire sans avoir à travailler sur le compilateur et passer par le gant d'acceptation open source est l'idée derrière cette discussion. À mon avis, la fixation de sync.Map est un cas réel qui définit en partie ce que devrait être cette proposition de génériques.

Si vous ajoutez sync.Map en tant que module intégré, jusqu'où allez-vous ? Faites-vous un cas particulier pour chaque conteneur ?
sync.Map n'est pas le seul conteneur et certains sont meilleurs dans certains cas que dans d'autres.

@Azareal : @chowey les a répertoriés en août :

Enfin, la bibliothèque standard est truffée d'alternatives d'interface{} où les génériques fonctionneraient de manière plus sûre :

• heap.Interface (https://golang.org/pkg/container/heap/#Interface)
• list.Element (https://golang.org/pkg/container/list/#Element)
• ring.Ring (https://golang.org/pkg/container/ring/#Ring)
• sync.Pool (https://golang.org/pkg/sync/#Pool)
• sync.Map à venir (https://tip.golang.org/pkg/sync/#Map)
• atomic.Value (https://golang.org/pkg/sync/atomic/#Value)

Il y en a peut-être d'autres qui me manquent. Le fait est que chacun des éléments ci-dessus est là où je m'attendrais à ce que les génériques soient utiles.

Et j'aimerais l'ensemble non ordonné pour les types qui peuvent être comparés pour l'égalité.

J'aimerais que beaucoup de travail soit consacré à une implémentation variable dans le runtime pour chaque type basé sur l'analyse comparative afin que la meilleure implémentation possible soit généralement celle qui est utilisée.

Je me demande s'il existe des implémentations alternatives raisonnables avec Go 1 qui atteignent le même objectif pour ces types de bibliothèques standard sans interface {} et sans génériques.

Les interfaces golang et les classes de type haskell surmontent deux choses (qui sont très bien !) :

1.) (Contrainte de type) Ils regroupent différents types avec une seule balise, le nom de l'interface
2.) (Dispatch) Ils proposent de dispatcher différemment sur chaque type pour un ensemble de fonctions donné via la mise en œuvre de l'interface

Mais,

1.) Parfois, vous ne voulez que des groupes anonymes comme un groupe int, float64 et string. Comment nommer une telle interface, NumericandString ?

2.) Très souvent, vous ne souhaitez pas répartir différemment chaque type d'interface, mais fournir une seule méthode pour tous les types d'interface répertoriés (peut-être possible avec les méthodes d'interface par défaut )

3.) Très souvent, vous ne voulez pas énumérer tous les types possibles pour un groupe. Au lieu de cela, vous allez paresseux et dites que je veux que tous les types T implémentent une interface A et le compilateur recherche ensuite tous les types dans tous les fichiers source que vous modifiez et dans toutes les bibliothèques que vous utilisez pour générer les fonctions appropriées au moment de la compilation.

Bien que le dernier point soit possible via le polymorphisme d'interface, il présente l'inconvénient d'être un polymorphisme d'exécution impliquant des transtypages et comment restreindre l'entrée de paramètre d'une fonction pour contenir des types implémentant plus d'une interface ou l'une des nombreuses interfaces. La solution consiste à introduire de nouvelles interfaces étendant d'autres interfaces (par imbrication d'interfaces) pour obtenir quelque chose de similaire, mais pas avec les meilleures pratiques.

D'ailleurs.
J'admets à ceux qui disent que go a déjà du polymorphisme et donc exactement go n'est plus un langage simple comme C. C'est un langage de programmation système de haut niveau. Alors pourquoi ne pas étendre les offres de polymorphisme go.

Voici une bibliothèque que j'ai commencée aujourd'hui pour les types d'ensembles génériques non ordonnés : https://github.com/pciet/unordered

Cela donne dans la documentation et les exemples de test qui type wrapper pattern (merci @pierrre) pour la sécurité du type au moment de la compilation et a également la vérification de réflexion pour la sécurité du type au moment de l'exécution.

Quels sont les besoins en génériques ? Mon attitude négative vis-à-vis des types génériques de bibliothèque standard était auparavant centrée sur l'utilisation d'interface{} ; ma plainte pourrait être résolue avec un type spécifique au package pour l'interface {} (comme type Item interface{} dans pciet/unordered) qui documente les contraintes non exprimables prévues.

Je ne vois pas la nécessité d'une fonctionnalité de langue supplémentaire alors que la simple documentation pourrait nous y amener maintenant. Il existe déjà de grandes quantités de code testé au combat dans la bibliothèque standard qui fournit des fonctionnalités génériques (voir https://github.com/golang/go/issues/23077).

Votre type de code vérifie lors de l'exécution (et de ce point de vue, ce n'est en aucun cas mieux que interface{} sinon pire). Avec les génériques, vous auriez pu avoir les types de collection avec des vérifications de type au moment de la compilation.

Les vérifications au moment de l'exécution @zerkms peuvent être désactivées en définissant asserting = false (cela n'irait pas dans la bibliothèque standard), il existe un modèle d'utilisation pour les vérifications au moment de la compilation, et de toute façon une vérification de type regarde simplement la structure d'interface (en utilisant l'interface ajoute plus de dépenses que la vérification de type). Si l'interface ne fonctionne pas, vous devrez écrire votre propre type.

Vous dites que le code générique aux performances maximisées est un besoin clé. Cela n'a pas été pour mes cas d'utilisation, mais peut-être que la bibliothèque standard pourrait devenir plus rapide, et peut-être que d'autres ont besoin d'une telle chose.

les contrôles d'exécution peuvent être désactivés en définissant asserting = false

alors rien ne garantit l'exactitude

Vous dites que le code générique aux performances maximisées est un besoin clé.

Je n'ai pas dit ça. La sécurité de type serait une bonne affaire. Votre solution est toujours interface{} -infectée.

mais peut-être que la bibliothèque standard pourrait devenir plus rapide, et peut-être que d'autres en ont besoin.

peut-être, si l'équipe de développement principale est heureuse de mettre en œuvre tout ce dont j'ai besoin à la demande et rapidement.

@pciet

Je ne vois pas la nécessité d'une fonctionnalité de langue supplémentaire alors que la simple documentation pourrait nous y amener maintenant.

Vous dites cela, mais vous n'avez aucun problème à utiliser les fonctionnalités génériques du langage sous la forme de tranches et la fonction make.

Je ne vois pas la nécessité d'une fonctionnalité de langue supplémentaire alors que la simple documentation pourrait nous y amener maintenant.

Alors pourquoi s'embêter à utiliser un langage typé statiquement ? Vous pouvez utiliser un langage typé dynamiquement comme Python et vous fier à la documentation pour vous assurer que les types de données corrects sont envoyés à votre API.

Je pense que l'un des avantages de Go est la possibilité d'imposer certaines contraintes au compilateur pour éviter de futurs bogues. Ces fonctionnalités peuvent être étendues (avec le support des génériques) pour appliquer d'autres contraintes afin d'éviter d'autres bogues à l'avenir.

Vous dites cela, mais vous n'avez aucun problème à utiliser les fonctionnalités génériques du langage sous la forme de tranches et la fonction make.

Je dis que les fonctionnalités existantes nous amènent à un bon point équilibré qui a des solutions de programmation génériques et qu'il devrait y avoir de bonnes raisons réelles de changer du système de type Go 1. Non pas comment un changement améliorerait le langage, mais quels problèmes les gens rencontrent actuellement, tels que le maintien d'un grand nombre de changements de type d'exécution pour l'interface {} dans les packages de bibliothèques standard fmt et base de données, qui seraient résolus.

Alors pourquoi s'embêter à utiliser un langage typé statiquement ? Vous pouvez utiliser un langage typé dynamiquement comme Python et vous fier à la documentation pour vous assurer que les types de données corrects sont envoyés à votre API.

J'ai entendu des suggestions pour écrire des systèmes en Python au lieu de langages et d'organisations à typage statique.

La plupart des programmeurs Go utilisant la bibliothèque standard utilisent des types qui ne peuvent pas être complètement décrits sans documentation ou sans regarder l'implémentation. Les types avec des sous-types paramétriques ou des types généraux avec des contraintes appliquées ne corrigent qu'un sous-ensemble de ces cas par programmation et généreraient beaucoup de travail déjà effectué dans la bibliothèque standard.

Dans la proposition pour les types de somme, j'ai suggéré une fonctionnalité de construction pour le commutateur de type d'interface où une interface utilisée dans une fonction ou une méthode a une erreur de construction émise lorsqu'une valeur possible attribuée à l'interface ne correspond à aucun cas de commutateur de type d'interface contenu.

Une fonction/méthode prenant une interface pourrait rejeter certains types lors de la construction en n'ayant aucun cas par défaut et aucun cas pour le type. Cela semble être un ajout de programmation générique raisonnable si la fonctionnalité est réalisable.

Si les interfaces Go pouvaient capturer le type de l'implémenteur, il pourrait y avoir une forme de génériques complètement compatible avec la syntaxe Go actuelle - une forme de générique à paramètre unique ( démonstration ).

@dc0d pour les types de conteneurs génériques, je pense que cette fonctionnalité ajoute une vérification de type au moment de la compilation sans nécessiter de type wrapper : https://gist.github.com/pciet/36a9dcbe99f6fb71f5fc2d3c455971e5

@pciet Vous avez raison. Dans le code fourni, n° 4, l'exemple indique que le type est capturé pour les tranches et les canaux (et les tableaux). Mais pas pour les cartes, car il n'y a qu'un seul et unique paramètre de type : l'implémenteur. Et comme une carte a besoin de deux paramètres de type, des interfaces wrapper sont nécessaires.

BTW, je dois mettre l'accent sur le but démonstratif de ce code, en tant que ligne de pensée. Je ne suis pas un concepteur de langage. Ceci n'est qu'une façon hypothétique de penser à l'implémentation des génériques dans Go :

• Compatible avec les Go actuels
• Simple (paramètre de type générique unique, qui _ressemble_ à _this_ dans d'autres OO, se référant à l'implémenteur actuel)

Discuter de la généricité et de tous les cas d'utilisation possibles dans le cadre d'une volonté de minimiser les impacts tout en maximisant les cas d'utilisation importants et la flexibilité d'expression est une analyse très complexe. Je ne sais pas si l'un d'entre nous sera en mesure de le résumer en un petit ensemble de principes, c'est-à-dire l'essence générative. J'essaie. Quoi qu'il en soit, voici quelques-unes de mes premières réflexions issues de ma lecture _cursory_ de ce fil…

@adg a écrit :

Ce numéro est accompagné d'une proposition générale de génériques par @ianlancetaylor qui comprend quatre propositions spécifiques erronées de mécanismes de programmation génériques pour Go.

Afaics, la section liée extraite comme suit ne parvient pas à indiquer un cas de généricité manquant avec les interfaces actuelles, _ "Il n'y a aucun moyen d'écrire une méthode qui prend une interface pour le type T fourni par l'appelant, pour tout T, et renvoie une valeur de le même type T.”_.

Il n'y a aucun moyen d'écrire une interface avec une méthode qui prend un argument de type T, pour tout T, et renvoie une valeur du même type.

Alors, comment le code du type de site d'appel pourrait-il vérifier qu'il a un type T comme valeur de résultat ? Par exemple, ladite interface peut avoir une méthode de fabrique pour construire le type T. C'est pourquoi nous devons paramétrer les interfaces sur le type T.

Les interfaces ne sont pas simplement des types ; ce sont aussi des valeurs. Il n'y a aucun moyen d'utiliser les types d'interface sans utiliser les valeurs d'interface, et les valeurs d'interface ne sont pas toujours efficaces.

Convenu que puisque les interfaces ne peuvent actuellement pas être explicitement paramétrées sur le type T sur lequel elles fonctionnent, le type T n'est pas accessible au programmeur.

Voici donc ce que font les limites de la classe de types sur le site de définition de la fonction en prenant comme entrée un type T et en ayant une clause where ou requires indiquant la ou les interfaces requises pour le type T. Dans de nombreuses circonstances ces dictionnaires d'interface peuvent être automatiquement monomorphisés au moment de la compilation afin qu'aucun pointeur de dictionnaire (pour les interfaces) ne soit transmis à la fonction au moment de l'exécution (monomorphisation que je suppose que le compilateur Go applique actuellement aux interfaces ?). Par "valeurs" dans la citation ci-dessus, je suppose qu'il entend le type d'entrée T et non le dictionnaire des méthodes pour le type d'interface implémenté par le type T.

Si nous autorisons ensuite les paramètres de type sur les types de données (par exemple struct ), alors ledit type T ci-dessus peut être lui-même paramétré, nous avons donc vraiment un type T<U> . Les usines pour de tels types qui doivent conserver la connaissance de U sont appelées types de type supérieur (HKT) .

Les génériques autorisent les conteneurs polymorphes de type sécurisé.

Cf également la question des conteneurs _hétérogènes_ discutée ci-dessous. Donc, par polymorphe, nous entendons la généricité du type de valeur du conteneur (par exemple, le type d'élément de la collection), mais il y a aussi la question de savoir si nous pouvons mettre plus d'un type de valeur dans le conteneur simultanément, ce qui les rend hétérogènes.

@tamird a écrit :

Ces exigences semblent exclure par exemple un système similaire au système de traits de Rust, où les types génériques sont contraints par des limites de traits.

Les limites de trait de Rust sont essentiellement des limites de classe de types.

@alex a écrit :

Les traits de Rust. Bien que je pense qu'ils soient un bon modèle en général, ils conviendraient mal au Go tel qu'il existe aujourd'hui.

Pourquoi pensez-vous qu'ils sont mal adaptés ? Peut-être pensez-vous aux objets de trait qui utilisent la répartition d'exécution et sont donc moins performants que le monomorphisme ? Mais ceux-ci peuvent être considérés séparément du principe de généricité des limites de classe de types (cf ma discussion sur les conteneurs/collections hétérogènes ci-dessous). Afaics, les interfaces de Go sont déjà des limites de type trait et accomplissent l'objectif des classes de types qui est de lier tardivement les dictionnaires aux types de données sur le site d'appel, plutôt que l'anti-modèle de la POO qui se lie tôt (même si encore à la compilation- temps) dictionnaires aux types de données (à l'instanciation/construction). Les classes de types peuvent (au moins une amélioration partielle des degrés de liberté) résoudre le problème d'expression que la POO ne peut pas.

@jimmyfrasche a écrit :

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

Je suis d'accord avec le lien ci-dessus sur le fait que les classes de types ne sous-typent pas et n'expriment aucune relation d'héritage. Et acceptez de ne pas confondre inutilement la «généricité» (en tant que concept plus général de réutilisation ou de modularité que le polymorphisme paramétrique) avec l'héritage comme le fait le sous-classement.

Cependant, je tiens également à souligner que les hiérarchies d'héritage (alias sous-typage) sont inévitables ¹ sur l'affectation à (entrées de fonction) et à partir de (sorties de fonction) si le langage prend en charge les unions et les intersections, car par exemple un int ν string peut accepter une affectation d'un int ou d'un string mais aucun ne peut accepter une affectation d'un int ν string . Sans union autant que je sache, les seuls moyens alternatifs de fournir des conteneurs / collections hétérogènes typés statiquement sont le polymorphisme de sous-classement ou existentiellement limité (alias objets de trait dans Rust et quantification existentielle dans Haskell). Les liens ci-dessus contiennent une discussion sur les compromis entre les existentiels et les syndicats. Afaik, la seule façon de faire des conteneurs/collections hétérogènes dans Go maintenant est de subsumer tous les types dans un interface{} vide qui jette les informations de typage et devrais-je présumer qu'il faudrait des casts et une inspection de type d'exécution, ce qui en quelque sorte ² défait le point de typage statique.

L '"anti-pattern" à éviter est le sous-classement , c'est-à-dire l'héritage virtuel (cf aussi "EDIT#2" sur les problèmes de subsomption et d'égalité implicites, etc.).

¹ _{Indépendamment du fait qu'ils correspondent structurellement ou nominalement, car le sous-typage est dû au principe de substitution de Liskov basé sur des ensembles comparatifs et la direction d'affectation avec des entrées de fonction opposées aux valeurs de retour, par exemple un paramètre de type d'un struct ou interface ne peut pas résider à la fois dans les entrées de la fonction et dans les valeurs de retour à moins qu'il soit invariant au lieu de co- ou contra-variant.}

² _{L'absolutisme ne s'appliquera pas parce que nous ne pouvons pas vérifier le type de l'univers du non-déterminisme illimité. Donc, si je comprends bien, ce fil concerne le choix d'une limite optimale («sweet spot») au niveau de la déclaration de frappe par rapport aux problèmes de généricité.}

@andrewcmyers a écrit :

Contrairement aux génériques Java et C#, le mécanisme des génériques Genus n'est pas basé sur le sous-typage.

C'est l'héritage et le sous-classement ( pas le sous-typage structurel ) qui est le pire anti-modèle que vous ne voulez pas copier depuis Java, Scala, Ceylan et C++ (sans rapport avec les problèmes avec les modèles C++ ).

@thwd a écrit :

L'exposant de la mesure de complexité des types paramétrés est la variance. Les types de Go (à l'exception des interfaces) sont invariants et cela peut et doit rester la règle.

Le sous-typage avec immuabilité évite la complexité de la covariance. L'immuabilité améliore également certains des problèmes de sous-classement (par exemple, Rectangle vs. Square ) mais pas d'autres (par exemple, subsomption implicite, égalité, etc.).

@bxqgit a écrit :

La syntaxe simple et le système de type sont les avantages importants de Go. Si vous ajoutez des génériques, le langage deviendra un vilain gâchis comme Scala ou Haskell.

Notez que Scala tente de fusionner OOP, sous-classification, FP, modules génériques, HKT et classes de types (via implicit ) en un seul PL. Peut-être que les classes de types seules pourraient suffire.

Haskell n'est pas nécessairement obtus à cause des génériques de classes de types, mais plus probablement parce qu'il applique des fonctions pures partout et utilise la théorie monadique des catégories pour modéliser des effets impératifs contrôlés.

Ainsi, je pense qu'il n'est pas correct d'associer l'obtusité et la complexité de ces PL avec des classes de type, par exemple dans Rust. Et ne blâmons pas les classes de types pour les durées de vie de Rust + l'abstraction exclusive d'emprunt de mutabilité.

Afaics, dans la section Semantics des _Type Parameters in Go_, le problème rencontré par @ianlancetaylor est un problème de conceptualisation car il (afaics) réinvente apparemment sans le vouloir les classes de types :

Pouvons-nous fusionner SortableSlice et PSortableSlice pour avoir le meilleur des deux mondes ? Pas assez; il n'y a aucun moyen d'écrire une fonction paramétrée qui prend en charge un type avec une méthode Less ou un type intégré. Le problème est que SortableSlice.Less ne peut pas être instancié pour un type sans une méthode Less , et il n'y a aucun moyen d'instancier une méthode uniquement pour certains types mais pas pour d'autres.

La clause requires Less[T] pour la classe de type liée (même si implicitement déduite par le compilateur) sur la méthode Less pour []T est sur T non []T . L'implémentation de la classe de types Less[T] (qui contient une méthode Less ) pour chaque T fournira soit une implémentation dans le corps de la fonction de la méthode, soit attribuera la < Fonction intégrée U[T] si les méthodes de Sortable[U] ont besoin d'un paramètre de type U représentant le type d'implémentation, par exemple []T . Afair @keean a une autre façon de structurer un tri en utilisant une classe de types distincte pour le type de valeur T qui ne nécessite pas de HKT.

Notez que ces méthodes pour []T peuvent implémenter une classe de type Sortable[U] , où U est []T .

(Aparté technique : il peut sembler que nous pourrions fusionner SortableSlice et PSortableSlice en ayant un mécanisme pour instancier une méthode uniquement pour certains arguments de type mais pas pour d'autres. Cependant, le résultat serait de sacrifier la compilation -time type safety, car l'utilisation du mauvais type conduirait à une panique d'exécution. Dans Go, on peut déjà utiliser des types et des méthodes d'interface et des assertions de type pour sélectionner le comportement au moment de l'exécution. Il n'est pas nécessaire de fournir un autre moyen de le faire en utilisant des paramètres de type .)

La sélection de la classe de types liée au site d'appel est résolue au moment de la compilation pour un T statiquement connu. Si une répartition dynamique hétérogène est nécessaire, consultez les options que j'ai expliquées dans mon message précédent.

J'espère que @keean pourra trouver le temps de venir ici et d'aider à expliquer les classes de types car il est plus expert et m'a aidé à apprendre ces concepts. J'ai peut-être des erreurs dans mon explication.

Remarque PS pour ceux qui ont déjà lu mon post précédent, notez que je l'ai édité en profondeur environ 10 heures après l'avoir posté (après un peu de sommeil) pour, espérons-le, rendre les points sur les conteneurs hétérogènes plus cohérents.

La section Cycles semble incorrecte. La construction à l'exécution de l'instance S[T]{e} d'un struct n'a rien à voir avec la sélection de l'implémentation de la fonction générique appelée. Il pense vraisemblablement que le compilateur ne sait pas s'il spécialise l'implémentation de la fonction générique pour le type des arguments, mais tous ces types sont connus au moment de la compilation.

Peut-être que la spécification de la section Type Checking pourrait être simplifiée en étudiant le concept de @keean d'un graphe connexe de types distincts en tant que nœuds pour un algorithme d'unification. Tous les types distincts connectés par une arête doivent avoir des types congruents, avec des arêtes créées pour tous les types qui se connectent via une affectation ou autrement dans le code source. S'il y a union et intersection (de mon post précédent), alors la direction de l'affectation doit être prise en compte (d'une manière ou d'une autre? ). Chaque type inconnu distinct commence par une borne supérieure (LUB) de Top et une borne inférieure (GLB) de Bottom , puis des contraintes peuvent modifier ces bornes. Les types connectés doivent avoir des bornes compatibles. Les contraintes doivent toutes être des limites de classe de types.

En implémentation :

Par exemple, il est toujours possible d'implémenter des fonctions paramétrées en générant une nouvelle copie de la fonction pour chaque instanciation, où la nouvelle fonction est créée en remplaçant les paramètres de type par les arguments de type.

Je crois que le terme technique correct est monomorphisation .

Cette approche donnerait le temps d'exécution le plus efficace au prix d'un temps de compilation supplémentaire considérable et d'une taille de code accrue. C'est probablement un bon choix pour les fonctions paramétrées qui sont suffisamment petites pour être intégrées, mais ce serait un mauvais compromis dans la plupart des autres cas.

Le profilage indiquerait au programmeur quelles fonctions peuvent le plus bénéficier de la monomorphisation. Peut-être que l'optimiseur Java Hotspot effectue l'optimisation de la monomorphisation au moment de l'exécution ?

@egonelbre a écrit :

Il y a Summary of Go Generics Discussions , qui tente de fournir un aperçu des discussions de différents endroits.

La section Vue d'ensemble semble impliquer que l'utilisation universelle par Java des références de boxe pour les instances dans un conteneur est le seul axe de conception diamétralement opposé à la monomorphisation des modèles de C++. Mais les limites de classe de types (qui peuvent également être implémentées avec des modèles C++ mais toujours monomorphisés) sont appliquées aux fonctions et non aux paramètres de type conteneur. Ainsi, afaics, la vue d'ensemble manque l'axe de conception pour les classes de types dans lequel nous pouvons choisir de monomorphiser chaque fonction délimitée de classe de types. Avec les classes de types, nous rendons toujours les programmeurs plus rapides (moins passe-partout) et pouvons obtenir un équilibre plus raffiné entre rendre les compilateurs/l'exécution plus rapides/plus lents et le gonflement du code plus/moins. Selon mon post précédent, peut-être que l'optimum serait si le choix des fonctions à monomorphiser était piloté par le profileur (automatiquement ou plus probablement par annotation).

Dans la section Problèmes : Structures de données génériques :

Les inconvénients

• Les structures génériques ont tendance à accumuler des fonctionnalités de toutes les utilisations, ce qui entraîne une augmentation des temps de compilation ou un gonflement du code ou nécessite un éditeur de liens plus intelligent.

Pour les classes de types, ce n'est pas vrai ou cela pose moins de problème, car les interfaces ne doivent être implémentées que pour les types de données qui sont fournis aux fonctions qui utilisent ces interfaces. Les classes de types concernent la liaison tardive de l'implémentation à l'interface, contrairement à la POO qui lie chaque type de données à ses méthodes pour l'implémentation class .

De plus, toutes les méthodes n'ont pas besoin d'être placées dans une seule interface. La clause requires (même si elle est implicitement déduite par le compilateur) sur une classe de type liée à une déclaration de fonction peut mélanger et assortir les interfaces requises.

• Les structures génériques et les API qui fonctionnent sur elles ont tendance à être plus abstraites que les API spécialement conçues, ce qui peut imposer une charge cognitive aux appelants

Un contre-argument qui, à mon avis, atténue considérablement cette préoccupation est que le fardeau cognitif de l'apprentissage d'un nombre illimité de réimplémentations de cas particuliers des mêmes algorithmes génériques est illimité. Alors que l'apprentissage des API génériques abstraites est limité.

• Les optimisations approfondies sont très non génériques et spécifiques au contexte, il est donc plus difficile de les optimiser dans un algorithme générique.

Ce n'est pas une escroquerie valide. La règle 80/20 dit de ne pas ajouter de complexité illimitée (par exemple, une optimisation prématurée) pour le code qui, une fois profilé, n'en a pas besoin. Le programmeur est libre d'optimiser dans 20 % des cas tandis que les 80 % restants sont gérés par la complexité limitée et la charge cognitive des API génériques.

Ce que nous voulons vraiment dire ici, c'est la régularité d'un langage et l'aide des API génériques, pas de mal à cela. Ces inconvénients ne sont vraiment pas correctement conceptualisés.

Solutions alternatives:

• utiliser des structures plus simples au lieu de structures compliquées
  
  
  
  • par exemple, utilisez map[int]struct{} au lieu de Set
  
  

Rob Pike (et je l'ai également vu faire valoir ce point dans la vidéo) semble ne pas comprendre que les conteneurs génériques ne suffisent pas pour créer des fonctions génériques. Nous avons besoin de ce T dans map[T] pour pouvoir passer le type de données générique dans les fonctions pour les entrées, les sorties et pour notre propre struct . Les génériques uniquement sur les paramètres de type de conteneur sont totalement insuffisants pour exprimer des API génériques et des API génériques sont nécessaires pour une complexité et une charge cognitive limitées et pour obtenir la régularité dans un écosystème de langage. De plus, je n'ai pas vu le niveau accru de refactorisation (donc la composabilité réduite des modules qui ne peuvent pas être facilement refactorisés) que le code non générique nécessite, ce qui est le problème d'expression que j'ai mentionné dans mon premier message.

Dans la section Approches génériques :

Modèles de package
Il s'agit d'une approche utilisée par Modula-3, OCaml, SML (appelés « foncteurs ») et Ada. Au lieu de spécifier un type individuel de spécialisation, l'ensemble du package est générique. Vous spécialisez le package en fixant les paramètres de type lors de l'importation.

Je peux me tromper mais cela ne semble pas tout à fait correct. Les foncteurs ML (à ne pas confondre avec les foncteurs FP) peuvent également renvoyer une sortie qui reste paramétrée par type. Sinon, il n'y aurait aucun moyen d'utiliser les algorithmes dans d'autres fonctions génériques, donc les modules génériques ne pourraient donc pas réutiliser (en important avec des types concrets dans) d'autres modules génériques. Cela semble être une tentative de simplifier à l'excès, puis de passer complètement à côté de l'intérêt des génériques, de la réutilisation des modules, etc.

Je crois plutôt que cette paramétrisation de type de package (alias module) permet d'appliquer des paramètres de type à un groupement de struct , interface et func .

Système de type plus compliqué
C'est l'approche adoptée par Haskell et Rust.
[…]
Les inconvénients:

• difficile à intégrer dans un langage plus simple (https://groups.google.com/d/msg/golang-nuts/smT_0BhHfBs/MWwGlB-n40kJ)

Citant @ianlancetaylor dans le document lié :

Si vous croyez cela, alors il vaut la peine de souligner que le cœur du
le code de carte et de tranche dans le runtime Go n'est pas générique dans le sens de
en utilisant le polymorphisme de type. Il est générique dans le sens où il regarde
tapez des informations de réflexion pour voir comment déplacer et comparer le type
valeurs. Nous avons donc la preuve par l'existence qu'il est acceptable d'écrire
code "générique" dans Go en écrivant du code non polymorphe qui utilise le type
informations de réflexion de manière efficace, puis pour envelopper ce code dans
passe-partout de type sécurisé au moment de la compilation (dans le cas de cartes et de tranches
cette plaque de chaudière est, bien sûr, fournie par le compilateur).

Et c'est ce qu'un compilateur transpilant à partir d'un sur-ensemble de Go avec des génériques ajoutés, afficherait sous forme de code Go. Mais l'emballage ne serait pas basé sur une délimitation telle que package, car cela n'aurait pas la composabilité que j'ai déjà mentionnée. Le fait est qu'il n'y a pas de raccourci vers un bon système de types de génériques composables. Soit nous le faisons correctement, soit nous ne faisons rien, car l'ajout d'un hack non composable qui n'est pas vraiment générique finira par créer une inertie de clusterfuck de patchwork à moitié générique et d'irrégularité des cas d'angle et des solutions de contournement faisant du code de l'écosystème Go inintelligible.

Il est également vrai que la plupart des gens qui écrivent de grands programmes Go complexes ont
pas constaté de besoin significatif de génériques. Jusqu'à présent, c'était plus comme
une verrue irritante - la nécessité d'écrire trois lignes passe-partout pour
chaque type à trier - plutôt qu'un obstacle majeur à l'écriture utile
code.

Oui, cela a été l'une des pensées dans mon esprit, à savoir si le passage à un système de classe de types complet est justifiable. Si toutes vos bibliothèques sont basées autour de cela, alors apparemment cela pourrait être une belle harmonie, mais si nous envisageons l'inertie des hacks Go existants pour la généricité, alors peut-être que la synergie supplémentaire obtenue sera faible pour beaucoup de projets ?

Mais si un transpileur à partir d'une syntaxe de classe de types émulait la manière manuelle existante dont Go peut modéliser les génériques (Modifier : ce que je viens de lire que @andrewcmyers déclare plausible ), cela pourrait être moins onéreux et trouver des synergies utiles. Par exemple, j'ai réalisé que deux classes de types de paramètres peuvent être émulées avec interface implémenté sur un struct qui émule un tuple, ou @jba a mentionné une idée pour employer en ligne interface en contexte . Apparemment, struct sont structurellement plutôt que nominalement typés à moins qu'on leur donne un nom avec type ? De plus, j'ai confirmé qu'une méthode d'un interface peut entrer un autre interface donc afaics il peut être possible de transpiler à partir de HKT dans votre exemple de tri dont j'ai parlé dans mon précédent post ici. Mais j'ai besoin d'y réfléchir davantage quand je n'ai pas si sommeil.

Je pense qu'il est juste de dire que la plupart des membres de l'équipe Go n'aiment pas C++
modèles, dans lesquels un langage complet de Turing a été superposé
un autre langage complet de Turing tel que les deux langages aient
syntaxes complètement différentes, et les programmes dans les deux langages sont
écrites de manière très différente. Les modèles C++ servent de mise en garde
conte parce que la mise en œuvre complexe a imprégné l'ensemble
bibliothèque standard, faisant des messages d'erreur C++ une source de
émerveillement et étonnement. Ce n'est pas un chemin que Go suivra jamais.

Je doute que quelqu'un soit en désaccord ! L'avantage de la monomorphisation est orthogonal aux inconvénients d'un moteur de métaprogrammation générique complet de Turing.

Au fait, l' erreur de conception des modèles C++ me semble être la même essence générative que la faille des foncteurs ML génératifs (par opposition aux foncteurs applicatifs). Le principe de moindre puissance s'applique.

@ianlancetaylor a écrit :

Il est décevant de voir Go devenir de plus en plus complexe en ajoutant des types paramétrés intégrés.

Malgré les spéculations dans ce numéro, je pense que cela est extrêmement peu probable.

J'espere. Je crois fermement que Go devrait soit ajouter un système de génériques cohérent, soit simplement accepter qu'il n'y aura jamais de génériques.

Je pense qu'un fork vers un transpiler est plus susceptible de se produire, en partie parce que j'ai des fonds pour le mettre en œuvre et que je suis intéressé à le faire. Pourtant, j'analyse toujours la situation.

Cela fracturerait l'écosystème, mais au moins alors Go peut rester pur à ses principes minimalistes. Ainsi, pour éviter de fracturer l'écosystème et permettre d' autres innovations que j'aimerais, je n'en ferais probablement pas un sur-ensemble et je l'appellerais plutôt Zéro .

@pciet a écrit :

Mon vote est non aux applications génériques généralisées, oui à des fonctions génériques plus intégrées telles que append et copy qui fonctionnent sur plusieurs types de base. Peut-être que sort et search pourraient être ajoutés pour les types de collection ?

L'expansion de cette inertie empêchera peut-être une fonctionnalité générique complète d'être intégrée à Go. Ceux qui voulaient des génériques sont susceptibles de partir vers des pâturages plus verts. @andrewcmyers a réitéré ceci :

Il serait ~is~ décevant de voir Go devenir de plus en plus complexe en ajoutant des types paramétrés intégrés. Il serait préférable d'ajouter simplement le support du langage pour que les programmeurs écrivent leurs propres types paramétrés.

@shelby3

Afaik, la seule façon de faire des conteneurs/collections hétérogènes dans Go maintenant est de subsumer tous les types dans une interface vide{} qui jette les informations de typage et devrais-je supposer nécessiter des casts et une inspection de type d'exécution, ce qui en quelque sorte2 va à l'encontre du point de typage statique.

Voir le modèle de wrapper dans les commentaires ci-dessus pour la vérification de type statique des collections interface{} dans Go.

Le fait est qu'il n'y a pas de raccourci vers un bon système de types de génériques composables. Soit on le fait correctement, soit on ne fait rien, car ajouter un hack non composable qui n'est pas vraiment générique…

Pouvez-vous expliquer cela davantage? Pour le cas des types de collection, avoir une interface définissant le comportement générique nécessaire des éléments contenus semble raisonnable pour écrire des fonctions.

@pciet ce code fait littéralement exactement ce que @ shelby3 décrivait et envisageait un antipattern. Je te cite plus tôt :

Cela donne dans la documentation et les exemples de test qui type wrapper pattern (merci @pierrre) pour la sécurité du type au moment de la compilation et a également la vérification de réflexion pour la sécurité du type au moment de l'exécution.

Vous prenez du code qui manque d'informations de type et, type par type, vous ajoutez des conversions et une inspection de type à l'exécution à l'aide de reflect. C'est exactement ce dont @ shelby3 se plaignait. J'ai tendance à appeler cette approche "monomorphisation à la main" et c'est exactement le genre de corvée fastidieuse que je pense qu'il vaut mieux confier à un compilateur.

Cette approche présente plusieurs inconvénients :

• Nécessite des wrappers type par type, maintenus soit à la main, soit avec un outil de type go generate
• (Si fait à la main au lieu d'un outil) possibilité de faire des erreurs dans le passe-partout qui ne seront détectées qu'au moment de l'exécution
• Nécessite une répartition dynamique au lieu d'une répartition statique, qui est à la fois plus lente et utilise plus de mémoire
• Utilise la réflexion d'exécution plutôt que les assertions de type au moment de la compilation, ce qui est également lent
• Non composable : agit entièrement sur des types concrets sans possibilité d'utiliser des limites de type typeclass (ou même de type interface) sur les types, à moins que vous ne manipuliez une autre couche d'indirection pour chaque interface non vide sur laquelle vous souhaitez également faire abstraction

Pouvez-vous expliquer cela davantage? Pour le cas des types de collection, avoir une interface définissant le comportement générique nécessaire des éléments contenus semble raisonnable pour écrire des fonctions.

Désormais, partout où vous souhaitez utiliser une borne à la place ou en plus d'un type concret, vous devez également écrire le même passe-partout de vérification de type pour chaque type d'interface. Cela ne fait qu'aggraver l'explosion (peut-être combinatoire) des wrappers de type statique que vous devez écrire.

Il y a aussi des idées qui, pour autant que je sache, ne peuvent tout simplement pas être exprimées dans le système de types de Go aujourd'hui, comme une limite sur une combinaison d'interfaces. Imaginons que nous ayons :

type Foo interface {
    ...
}

type Bar interface {
    ...
}

Comment exprimons-nous, en utilisant une vérification de type purement statique, que nous voulons un type qui implémente à la fois Foo et Bar ? Autant que je sache, cela n'est pas possible dans Go (à moins de recourir à des vérifications d'exécution qui peuvent échouer, en évitant la sécurité de type statique).

Avec un système de génériques basé sur les classes de types, nous pourrions exprimer cela comme suit :

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

@tarcieri

Comment exprimons-nous, en utilisant une vérification de type purement statique, que nous voulons un type qui implémente à la fois Foo et Bar ?

simplement comme ceci :

type T interface {
    Foo
    Bar
}

func baz(t T) { ... }

@sbinet soigné, TIL

Personnellement, je considère la réflexion d'exécution comme une mauvaise fonctionnalité, mais ce n'est que moi ... Je peux expliquer pourquoi si quelqu'un est intéressé.

Je pense que toute personne implémentant des génériques de quelque nature que ce soit devrait d'abord lire plusieurs fois "Elements of Programming" de Stepanov. Cela éviterait beaucoup de problèmes non inventés ici et réinventerait la roue. Après avoir lu cela, il devrait être clair pourquoi "C++ Concepts" et "Haskell Typeclasses" sont la bonne façon de faire des génériques.

Je vois que ce problème semble à nouveau actif
Voici un terrain de jeu de proposition d'homme de paille
https://go-li.github.io/test.html
collez simplement les programmes de démonstration d'ici
https://github.com/go-li/demo

Merci beaucoup pour votre évaluation de ce paramètre unique
fonctions génériques.

Nous maintenons le gccgo piraté et
ce projet aurait été impossible sans vous, alors nous
voulait contribuer en retour.

Nous attendons également avec impatience les génériques que vous adopterez, continuez votre excellent travail !

@anlhord où sont les détails de mise en œuvre à ce sujet ? Où peut-on lire la syntaxe ? Qu'est-ce qui est implémenté ? Qu'est-ce qui n'est pas implémenté ? Quelles sont les spécifications de ces implémentations ? Quels en sont les avantages et les inconvénients ?

Le lien du terrain de jeu en contient le pire exemple possible :

package main

import "fmt"

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

Ce code ne me dit rien sur la façon de l'utiliser et que puis-je tester.

Si vous pouviez améliorer ces choses, cela aiderait à mieux comprendre quelle est votre proposition et comment elle se compare aux précédentes / voir comment les autres points soulevés ici s'y appliquent ou non.

J'espère que cela vous aide à comprendre les problèmes avec votre commentaire.

@joho a écrit :

La littérature universitaire aurait-elle de la valeur pour des conseils sur l'évaluation des approches ?

Le seul article que j'ai lu sur le sujet est Les développeurs bénéficient-ils des types génériques ? (paywall désolé, vous pourriez chercher sur Google votre chemin vers un téléchargement pdf) qui avait ce qui suit à dire

Par conséquent, une interprétation conservatrice de l'expérience
est que les types génériques peuvent être considérés comme un compromis
entre les caractéristiques positives de la documentation et
caractéristiques d'extensibilité négatives.

Je présume que la POO et les sous-classes (par exemple, les classes en Java et C++) ne seront pas prises au sérieux car Go a déjà une classe de type interface (sans le paramètre de type générique explicite T ), Java est cité comme ce qu'il ne faut pas copier, et parce que beaucoup ont fait valoir qu'ils sont un anti-modèle. Upthread J'ai lié à une partie de cet argument. Nous pourrions approfondir cette analyse si quelqu'un est intéressé.

Je n'ai pas encore étudié de recherches plus récentes telles que le système Genus mentionné upthread . Je me méfie des systèmes "d'évier de cuisine" qui tentent de mélanger tant de paradigmes (par exemple sous-classement, héritage multiple, OOP, linéarisation des traits, implicit , classes de types, types abstraits, etc.), en raison des plaintes concernant Scala avoir autant de cas d'angle dans la pratique, bien que cela s'améliorera peut-être avec Scala 3 (alias Dotty et le calcul DOT). Je suis curieux de savoir si leur tableau de comparaison se compare à Scala 3 expérimental ou à la version actuelle de Scala ?

Donc afaics, ce qui reste sont les foncteurs ML et les classes de types Haskell en termes de systèmes de généricité éprouvés, qui améliorent considérablement l'extensibilité et la flexibilité par rapport à la sous-classification OOP +.

J'ai écrit une partie de la discussion privée @keean et j'ai eu à propos des modules de foncteurs ML par rapport aux classes de types. Les points forts semblent être :

• les classes de type _modélisent une algèbre_ (mais sans les axiomes vérifiés ) et implémentent chaque type de données pour chaque interface d'une seule manière. Permettant ainsi une sélection implicite des implémentations par le compilateur sans annotation sur le site d'appel.

• Les foncteurs applicatifs ont une transparence référentielle alors que les foncteurs génératifs créent une nouvelle instance à chaque instanciation, ce qui signifie qu'ils ne sont pas invariants à l'ordre d'initialisation.

• Les foncteurs ML sont plus puissants/flexibles que les classes de types, mais cela se fait au prix de plus d'annotations et potentiellement plus d'interactions de cas extrêmes. Et selon @keean, ils nécessitent des types dépendants (pour les types associés ) qui sont un système de type plus complexe. @keean pense que l'_expression de la généricité de Stepanov en tant qu'algèbre_ plus les classes de types est suffisamment puissante et flexible , ce qui semble être le point idéal pour une généricité de pointe et bien éprouvée (dans Haskell et maintenant dans Rust). Cependant, les axiomes ne sont pas appliqués par les classes de types.

• J'ai suggéré d'ajouter des unions pour les conteneurs hétérogènes avec des classes de types à étendre le long d'un autre axe du problème d'expression, bien que cela nécessite l'immuabilité ou la copie (uniquement pour les cas où l'extensibilité hétérogène est utilisée) qui est connue pour avoir un O(log n) ralentissement par rapport à l'impérativité mutable effrénée.

@larsth a écrit :

Il pourrait être intéressant d'avoir un ou plusieurs transpileurs expérimentaux - un code source générique Go vers un compilateur de code source Go 1.xy.

_{PS Je doute que Go adopte un système de typage aussi sophistiqué, mais j'envisage un transpiler à la syntaxe Go existante comme je l'ai mentionné dans mon post précédent (voir la modification en bas). Et je veux un système générique robuste avec ces fonctionnalités Go très souhaitables. Les génériques Typeclass sur Go semblent être ce que je veux.}

@bcmills a écrit à propos de sa proposition sur les fonctions de compilation pour la généricité :

J'ai entendu le même argument utilisé pour préconiser l'exportation de types interface plutôt que de types concrets dans les API Go, et l'inverse s'avère plus courant : l'abstraction prématurée surcontraint les types et entrave l'extension des API. (Pour un tel exemple, voir # 19584.) Si vous voulez vous appuyer sur cette ligne d'argumentation, je pense que vous devez fournir des exemples concrets.

Il est certainement vrai que les abstractions du système de types abandonnent nécessairement certains degrés de liberté et parfois nous avons éliminé ces contraintes avec "unsafe" (c'est-à-dire en violation de l'abstraction vérifiée statiquement), mais cela doit être échangé contre les avantages de découplage modulaire avec des invariants succinctement annotés.

Lors de la conception d'un système pour la généricité, nous souhaitons probablement augmenter la régularité et la prévisibilité de l'écosystème comme l'un des principaux objectifs, en particulier si la philosophie de base de Go est prise en compte (par exemple, les programmeurs moyens sont une priorité).

Le principe de moindre puissance s'applique. La puissance/flexibilité des invariants "cachés dans" les fonctions de compilation pour la généricité doit être mise en balance avec leur capacité à nuire, par exemple, à la lisibilité du code source dans l'écosystème (où le découplage modulaire est extrêmement important car le lecteur ne pas besoin de lire une quantité de code potentiellement illimitée en raison de dépendances transitives implicites, afin de comprendre un module/package donné !). La résolution implicite des instances d'implémentation de classe de types présente ce problème si leur algèbre n'est pas respectée .

Bien sûr, mais c'est déjà vrai pour de nombreuses contraintes implicites dans Go, indépendamment de tout mécanisme de programmation générique.

Par exemple, une fonction peut recevoir un paramètre de type interface et appeler initialement ses méthodes séquentiellement. Si cette fonction change ultérieurement pour appeler ces méthodes simultanément (en engendrant des goroutines supplémentaires), la contrainte "doit être sûre pour une utilisation simultanée" n'est pas reflétée dans le système de type.

Mais autant que je sache, Go n'a pas tenté de concevoir une abstraction pour modulariser ces effets. Rust a une telle abstraction (ce qui, je pense, est exagéré pita/tsuris/limitant pour certains/la plupart des cas d'utilisation et je plaide pour une abstraction de modèle à un seul thread plus facile, mais malheureusement, Go ne prend pas en charge la restriction de toutes les goroutines générées au même thread ) . Et Haskell nécessite un contrôle monadique sur les effets en raison de l'application de fonctions pures pour la transparence référentielle .

@alerca a écrit :

Je pense que le plus gros inconvénient des contraintes inférées est qu'elles facilitent l'utilisation d'un type d'une manière qui introduit une contrainte sans la comprendre pleinement. Dans le meilleur des cas, cela signifie simplement que vos utilisateurs peuvent rencontrer des échecs de compilation inattendus, mais dans le pire des cas, cela signifie que vous pouvez casser le package pour les consommateurs en introduisant une nouvelle contrainte par inadvertance. Des contraintes explicitement spécifiées éviteraient cela.

D'accord. Être capable de casser subrepticement du code dans d'autres modules parce que les invariants des types ne sont pas explicitement annotés est extrêmement insidieux.

@andrewcmyers a écrit :

Pour être clair, je ne considère pas que la génération de code de style macro, qu'elle soit effectuée avec gen, cpp, gofmt -r ou d'autres outils de macro/modèle, soit une bonne solution au problème des génériques, même si elle est standardisée. Il a les mêmes problèmes que les templates C++ : gonflement du code, manque de vérification de type modulaire et difficulté de débogage. Cela s'aggrave au fur et à mesure que vous commencez, comme c'est naturel, en construisant du code générique en termes d'autre code générique. À mon avis, les avantages sont limités : cela rendrait la vie relativement simple aux auteurs du compilateur Go et cela produirait un code efficace - à moins qu'il n'y ait une pression sur le cache d'instructions, une situation fréquente dans les logiciels modernes !

@keean semble être d'accord avec vous.

@ shelby3 merci pour les commentaires. Pouvez-vous la prochaine fois faire les commentaires/modifications directement dans le document lui-même. Il est plus facile de suivre où les choses doivent être corrigées et plus facile de s'assurer que toutes les notes obtiennent une réponse appropriée.

La section Présentation semble impliquer que l'utilisation universelle par Java des références de boxe pour les instances ...

Ajout d'un commentaire pour préciser qu'il ne s'agit pas d'une liste exhaustive. C'est principalement là pour que les gens comprennent l'essentiel des différents compromis. La liste complète des différentes approches est présentée ci-dessous.

Les structures génériques ont tendance à accumuler des fonctionnalités de toutes les utilisations, ce qui entraîne une augmentation des temps de compilation ou un gonflement du code ou nécessite un éditeur de liens plus intelligent.
Pour les classes de types, ce n'est pas vrai ou cela pose moins de problème, car les interfaces ne doivent être implémentées que pour les types de données qui sont fournis aux fonctions qui utilisent ces interfaces. Les classes de type concernent la liaison tardive de l'implémentation à l'interface, contrairement à la POO qui lie chaque type de données à ses méthodes pour l'implémentation de la classe.

Cette déclaration concerne ce qui arrive aux structures de données génériques à long terme. En d'autres termes, une structure de données générique finit souvent par collecter toutes les utilisations différentes - plutôt que d'avoir plusieurs implémentations plus petites à des fins différentes. Juste à titre d'exemple, regardez https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html.

Il est important de noter que la "conception mécanique" et "autant de flexibilité" ne suffisent pas pour créer une bonne "solution générique". Il a également besoin de bonnes instructions, de la manière dont les choses doivent être utilisées et de ce qu'il faut éviter, et de la manière dont les gens finissent par l'utiliser.

Les structures génériques et les API qui fonctionnent dessus ont tendance à être plus abstraites que les API spécialement conçues...

Un contre-argument qui, à mon avis, atténue considérablement cette préoccupation est que le fardeau cognitif de l'apprentissage d'un nombre illimité de réimplémentations de cas particuliers des mêmes algorithmes génériques, est illimité ...

Ajout d'une note sur la charge cognitive de nombreuses API similaires.

Les réimplémentations de cas particuliers ne sont pas illimitées dans la pratique. Vous ne verrez qu'un nombre fixe de spécialisations.

Ce n'est pas une escroquerie valide.

Vous pouvez être en désaccord avec certains points, je suis en désaccord avec un certain nombre d'entre eux dans une certaine mesure, mais je comprends leur point de vue et j'essaie de comprendre les problèmes auxquels les gens sont confrontés au quotidien. Le but du document est de recueillir des opinions différentes, pas de juger "à quel point quelque chose est ennuyeux pour quelqu'un".

Cependant, le document prend position sur les "problèmes liés aux problèmes du monde réel", car les problèmes abstraits et facilités dans les forums ont tendance à se transformer en bavardage sans signification sans qu'aucune compréhension ne soit construite.

Ce que nous voulons vraiment dire ici, c'est la régularité d'un langage et l'aide des API génériques, pas de mal à cela.

Bien sûr, dans la pratique, vous n'aurez besoin de ce style d'optimisation que pour moins de 1% des cas.

Solutions alternatives:

Les solutions alternatives ne sont pas censées se substituer aux génériques. Mais plutôt une liste de solutions potentielles pour différents types de problèmes.

Modèles de package

Je peux me tromper mais cela ne semble pas tout à fait correct. Les foncteurs ML (à ne pas confondre avec les foncteurs FP) peuvent également renvoyer une sortie qui reste paramétrée par type.

Pouvez-vous fournir une formulation plus claire et, si nécessaire, scinder en deux approches différentes ?

@egonelbre merci également d'avoir répondu afin que je puisse savoir sur quels points je dois clarifier davantage ma pensée.

Pouvez-vous la prochaine fois faire les commentaires/modifications directement dans le document lui-même.

Mes excuses, j'aimerais pouvoir me conformer, mais je n'ai jamais utilisé les fonctionnalités de discussion de Google Doc, je n'ai pas le temps de l'apprendre, et je préfère également pouvoir créer un lien vers mes discussions sur Github pour référence future.

Juste à titre d'exemple, regardez https://www.scala-lang.org/api/2.12.3/scala/collection/immutable/List.html.

La conception de la bibliothèque des collections Scala a été critiquée par de nombreuses personnes, dont l'un des anciens membres clés de l'équipe . Un commentaire posté sur LtU est représentatif. Notez que j'ai ajouté ce qui suit à l'un de mes messages précédents dans ce fil pour résoudre ce problème :

Je me méfie des systèmes "d'évier de cuisine" qui tentent de mélanger tant de paradigmes (par exemple sous-classement, héritage multiple, POO, linéarisation des traits, implicit , classes de types, types abstraits, etc.), en raison des plaintes concernant Scala avoir autant de cas d'angle dans la pratique, bien que cela s'améliorera peut-être avec Scala 3 (alias Dotty et le calcul DOT).

Je ne pense pas que la bibliothèque de collections de Scala soit représentative des bibliothèques créées pour un PL avec uniquement des classes de types pour le polymorphisme. Afair, les collections Scala utilisent l' anti-modèle d'héritage , qui a causé les hiérarchies complexes, combiné avec des aides implicit telles que CanBuildFrom qui ont fait exploser le budget de complexité. Et je pense que si le point de @keean est respecté sur le fait que _Elements of Programming_ de Stepanov est une algèbre , une élégante bibliothèque de collections pourrait être créée. C'était la première alternative que j'avais vue à une bibliothèque de collections basée sur un foncteur (FP) (c'est-à-dire ne copiant pas Haskell ) également basée sur les mathématiques. Je veux voir cela dans la pratique, ce qui est l'une des raisons pour lesquelles je collabore/discute avec lui sur la conception d'un nouveau PL. Et à partir de ce moment, je prévois de faire d'abord transpiler cette langue en Go (bien que j'essaie depuis des années de trouver un moyen d'éviter de le faire). J'espère donc que nous pourrons bientôt expérimenter pour voir comment cela fonctionne.

Ma perception est que la communauté/philosophie Go préfère attendre de voir ce qui fonctionne dans la pratique et l'adopter plus tard une fois prouvé, que de se précipiter et de polluer le langage avec des expériences ratées. Parce que, comme vous l'avez répété, toutes ces affirmations abstraites ne sont pas si constructives (sauf peut-être pour les théoriciens de la conception PL). De plus, il est probablement invraisemblable de concevoir un système de génériques cohérent par comité.

Il a également besoin de bonnes instructions, de la manière dont les choses doivent être utilisées et de ce qu'il faut éviter, et de la manière dont les gens finissent par l'utiliser.

Et je pense que cela aidera à ne pas mélanger autant de paradigmes différents disponibles pour le programmeur dans le même langage. Ce n'est apparemment pas nécessaire ( @keean et moi devons prouver cette affirmation). Je pense que nous adhérons tous les deux à la philosophie selon laquelle le budget de complexité est fini et c'est ce que vous laissez en dehors du PL qui est aussi important que les fonctionnalités incluses.

Cependant, le document prend position sur les "problèmes liés aux problèmes du monde réel", car les problèmes abstraits et facilités dans les forums ont tendance à se transformer en bavardage sans signification sans qu'aucune compréhension ne soit construite.

D'accord. Et il est également difficile pour tout le monde de suivre les points abstraits. Le diable est dans les détails et les résultats réels dans la nature.

Bien sûr, dans la pratique, vous n'aurez besoin de ce style d'optimisation que pour moins de 1% des cas.

Go a déjà interface pour la généricité, ce qui permet de gérer les cas où le polymorphisme paramétrique n'est pas nécessaire sur le type T pour l'instance de l'interface fournie par le site d'appel.

Je pense avoir lu quelque part, peut-être était-il en amont, l'argument selon lequel la bibliothèque standard de Go souffre en fait d'une incohérence dans l'utilisation optimale des idiomes les plus mis à jour. Je ne sais pas si c'est vrai, car je n'ai pas encore d'expérience avec Go. Ce que je veux dire, c'est que le paradigme des génériques choisi infecte toutes les bibliothèques. Alors oui, à partir de maintenant, vous pouvez prétendre que seulement 1% du code en aurait besoin, car il y a déjà une inertie dans les idiomes qui évitent le besoin de génériques.

Vous avez peut-être raison. J'ai aussi mon scepticisme quant à la mesure dans laquelle j'utiliserai une fonctionnalité linguistique particulière. Je pense que l'expérimentation pour découvrir est la voie que je vais procéder. La conception PL est un processus itératif, alors le problème est de lutter contre l'inertie qui se développe rend difficile l'itération du processus. Je suppose donc que Rob Pike a raison dans la vidéo où il suggère d'écrire des programmes qui écrivent du code pour les programmes (c'est-à-dire des outils de génération d'écriture et des transpilers) pour expérimenter et tester des idées.

Lorsque nous pouvons montrer qu'un ensemble particulier de fonctionnalités est supérieur dans la pratique (et, espérons-le, également dans la popularité d'utilisation) à ceux actuellement en Go, alors nous pouvons peut-être voir une forme de consensus autour de leur ajout à Go. J'encourage les autres à créer également des systèmes expérimentaux qui se transpilent au Go.

Pouvez-vous fournir une formulation plus claire et, si nécessaire, scinder en deux approches différentes ?

J'ajoute ma voix à ceux qui voudraient décourager la tentative de mettre une fonctionnalité de modélisation trop simpliste dans Go et prétendre qu'il s'agit de génériques. IOW, je pense qu'un système de génériques fonctionnant correctement et qui ne finira pas par être une mauvaise inertie est fondamentalement incompatible avec le désir d'avoir une conception trop simpliste pour les génériques. Afaik, un système de génériques a besoin d'une conception holistique bien pensée et éprouvée. Faisant écho à ce que @larsth a écrit , j'encourage ceux qui ont des propositions sérieuses à d'abord construire un transpiler (ou à implémenter dans un fork de l'interface gccgo) puis à expérimenter la proposition afin que nous puissions tous mieux comprendre ses limites. J'ai été encouragé à lire en amont que @ianlancetaylor ne pensait pas qu'une pollution de mauvaise inertie serait ajoutée au Go. En ce qui concerne ma plainte spécifique concernant la proposition de paramétrage au niveau du package, ma suggestion pour celui qui la propose, veuillez envisager de créer un compilateur que nous pouvons tous utiliser pour jouer avec, puis nous pouvons tous parler d'exemples de ce que nous aimons et ne faisons pas ' Je n'aime pas ça. Sinon, nous nous parlons parce que je ne comprends peut-être même pas correctement la proposition telle qu'elle est décrite de manière abstraite. Je ne dois pas comprendre la proposition, car je ne comprends pas comment le package paramétré peut être réutilisé dans un autre package également paramétré. IOW, si un package prend des paramètres, il doit également instancier d'autres packages avec des paramètres. Mais il semblait que la proposition indiquait que la seule façon d'instancier un package paramétré était avec un type concret, pas avec des paramètres de type.

Des excuses si interminables. Je veux m'assurer que je ne suis pas mal compris.

@ shelby3 ah, j'ai alors mal compris la plainte initiale. Tout d'abord, je dois préciser que les sections des "Approches génériques" ne sont pas des propositions concrètes. Ce sont des approches ou, en d'autres termes, des décisions de conception plus importantes que l'on pourrait prendre dans une approche générique concrète. Cependant, les regroupements sont fortement motivés par des implémentations existantes ou des propositions concrètes/informelles. De plus, je soupçonne qu'il manque encore au moins 5 grandes idées dans cette liste.

Pour l'approche "modèles de packages", il existe deux variantes (voir les discussions liées dans le document):

1. packages génériques basés sur "l'interface",
2. paquets explicitement génériques.

Pour 1. il n'est pas nécessaire que le package générique fasse quoi que ce soit de spécial - par exemple, le container/ring actuel deviendrait utilisable pour la spécialisation. Imaginez la "spécialisation" ici comme le remplacement de toutes les instances de l'interface dans le package par le type concret (et en ignorant les importations circulaires). Lorsque ce paquet lui-même spécialise un autre paquet, il peut utiliser "l'interface" comme spécialisation - il s'ensuit que cette utilisation sera également spécialisée.

Pour 2. vous pouvez les regarder de deux manières. L'un est la spécialisation concrète récursive à chaque importation - similaire à la modélisation/macroisation, à aucun moment il n'y aurait de "paquet partiellement appliqué". Bien sûr, on peut également voir, du côté fonctionnel, que le package générique est un partiel avec des paramètres, puis vous le spécialisez.

Donc, oui, vous pouvez utiliser un package paramétré dans un autre.

Faisant écho à ce que @larsth a écrit, j'encourage ceux qui ont des propositions sérieuses à d'abord construire un transpiler (ou à implémenter dans un fork de l'interface gccgo) puis à expérimenter la proposition afin que nous puissions tous mieux comprendre ses limites.

Je sais que ce n'était pas explicitement dirigé vers cette approche, mais il y a 4 prototypes différents pour tester l'idée. Bien sûr, ce ne sont pas des transpilateurs complets, mais ils sont suffisants pour tester quelques idées. c'est-à-dire que je ne suis pas sûr que quelqu'un ait implémenté le cas "utiliser un package paramétré d'un autre".

Les packages paramétrés ressemblent beaucoup à des modules ML (et les foncteurs ML sont les paramètres peuvent être d'autres packages). Il y a deux manières dont ceux-ci peuvent fonctionner "applicatif" ou "génératif". Un foncteur applicatif est comme une valeur ou un alias de type. Un foncteur génératif doit être construit et chaque instance est différente. Une autre façon de penser à cela est que pour qu'un package soit applicatif, il doit être pur (c'est-à-dire qu'il n'y a pas de variables mutables au niveau du package). S'il y a un état au niveau du package, il doit être génératif car cet état doit être initialisé, et il importe quelle "instance" d'un package génératif vous transmettez réellement en tant que paramètre à d'autres packages qui à leur tour doivent être génératifs. Par exemple, les packages Ada sont génératifs.

Le problème avec l'approche de package génératif est qu'elle crée beaucoup de passe-partout, où vous instanciez des packages avec des paramètres. Vous pouvez regarder les génériques d'Ada pour voir à quoi cela ressemble.

Les classes de type évitent ce passe-partout en sélectionnant implicitement la classe de type en fonction des types utilisés dans la fonction uniquement. Vous pouvez également voir les classes de types comme une surcharge contrainte avec une distribution multiple, où la résolution de surcharge se produit presque toujours de manière statique au moment de la compilation, avec des exceptions pour la récursivité polymorphe et les types existentiels (qui sont essentiellement des variantes que vous ne pouvez pas chasser, vous ne pouvez utiliser les interfaces avec lesquelles la variante confirme).

Un foncteur applicatif est comme une valeur ou un alias de type. Un foncteur génératif doit être construit et chaque instance est différente. Une autre façon de penser à cela est que pour qu'un package soit applicatif, il doit être pur (c'est-à-dire qu'il n'y a pas de variables mutables au niveau du package). S'il y a un état au niveau du package, il doit être génératif car cet état doit être initialisé, et il importe quelle "instance" d'un package génératif vous transmettez réellement en tant que paramètre à d'autres packages qui à leur tour doivent être génératifs. Par exemple, les packages Ada sont génératifs.

Merci pour la terminologie exacte, je dois réfléchir à la façon d'intégrer ces idées dans le document.

De plus, je ne vois pas pourquoi vous ne pourriez pas avoir un "alias de type automatique vers un package généré" - en quelque sorte quelque chose entre l'approche "foncteur applicatif" et "foncteur génératif". De toute évidence, lorsque le package contient une forme d'état, il peut devenir compliqué à déboguer et à comprendre.

Le problème avec l'approche de package génératif est qu'elle crée beaucoup de passe-partout, où vous instanciez des packages avec des paramètres. Vous pouvez regarder les génériques d'Ada pour voir à quoi cela ressemble.

Autant que je sache, cela créerait moins de passe-partout que les modèles C++ mais plus que les classes de type. Avez-vous un bon programme du monde réel pour Ada qui illustre le problème ? _(Par monde réel, je veux dire le code que quelqu'un utilise/utilisait en production.)_

Bien sûr, jetez un œil à mon go-board Ada : https://github.com/keean/Go-Board-Ada/blob/master/go.adb

Bien qu'il s'agisse d'une définition assez vague de la production, le code est optimisé, fonctionne aussi bien que la version C++ et son open-source, et l'algorithme a été affiné sur plusieurs années. Vous pouvez également consulter la version C++ : https://github.com/keean/Go-Board/blob/master/go.cpp

Cela montre (je pense) que les génériques Ada sont une solution plus soignée que les modèles C++ (mais ce n'est pas difficile), d'autre part, il est difficile de faire l'accès rapide aux structures de données dans Ada en raison des restrictions sur le retour d'une référence .

Si vous voulez regarder un système de génériques de paquets pour un langage impératif, je pense qu'Ada est l'un des meilleurs à regarder. C'est dommage qu'ils aient décidé d'aller multi-paradigmes et d'ajouter tous les trucs OO à Ada. Ada est un Pascal amélioré, et Pascal était un langage petit et élégant. Les génériques Pascal plus Ada auraient été encore un tout petit langage, mais auraient été bien meilleurs à mon avis. Parce que l'accent d'Ada s'est déplacé vers une approche OO, trouver une bonne documentation et des exemples sur la façon de faire les mêmes choses avec des génériques semble difficile à trouver.

Bien que je pense que les classes de types ont certains avantages, je pourrais vivre avec les génériques de style Ada, il y a quelques problèmes qui m'empêchent d'utiliser Ada plus largement, je pense que les valeurs/objets sont erronés (je pense que très peu de langages obtiennent ce droit, 'C' étant l'un des seuls), il est difficile de travailler avec des pointeurs (variables d'accès) et de créer des abstractions de pointeur sûr, et il ne fournit pas un moyen d'utiliser des packages avec un polymorphisme d'exécution (il fournit un modèle d'objet pour cela, mais cela ajoute un tout nouveau paradigme au lieu d'essayer de trouver un moyen d'avoir un polymorphisme d'exécution à l'aide de packages).

La solution au polymorphisme d'exécution est de créer des packages de première classe afin que les instances de signatures de packages puissent être transmises en tant qu'arguments de fonction, cela nécessite malheureusement des types dépendants (voir le travail effectué sur les types d'objets dépendants pour Scala pour éliminer le gâchis qu'ils ont créé avec leur système de type d'origine).

Je pense donc que les génériques de packages peuvent fonctionner, mais il a fallu des décennies à Ada pour traiter tous les cas extrêmes, donc je regarderais un système de génériques de production pour voir quels raffinements utilisent dans la production produite. Cependant, Ada est toujours en deçà car les packages ne sont pas de première classe et ne peuvent pas être utilisés dans le polymorphisme d'exécution, et cela devrait être résolu.

@keean a écrit :

Personnellement, je considère la réflexion d'exécution comme une mauvaise fonctionnalité, mais ce n'est que moi ... Je peux expliquer pourquoi si quelqu'un est intéressé.

L'effacement de type active "Theorems for free", ce qui a des implications pratiques . La réflexion d'exécution inscriptible (et peut-être même lisible en raison de relations transitives avec le code impératif ?) rend impossible de garantir la transparence référentielle dans n'importe quel code et donc certaines optimisations du compilateur ne sont pas possibles et les monades sécurisées de type ne sont pas possibles. Je me rends compte que Rust n'a même pas encore de fonctionnalité d'immuabilité. OTOH, la réflexion permet d'autres optimisations qui ne seraient autrement pas possibles si elles ne pouvaient pas être typées statiquement.

J'avais également indiqué upthread:

Et c'est ce qu'un compilateur transpilant à partir d'un sur-ensemble de Go avec des génériques ajoutés, afficherait sous forme de code Go. Mais l'emballage ne serait pas basé sur une délimitation telle que package, car cela n'aurait pas la composabilité que j'ai déjà mentionnée. Le fait est qu'il n'y a pas de raccourci vers un bon système de types de génériques composables. Soit nous le faisons correctement, soit nous ne faisons rien, car l'ajout d'un hack non composable qui n'est pas vraiment générique finira par créer une inertie de clusterfuck de patchwork à moitié générique et d'irrégularité des cas d'angle et des solutions de contournement faisant du code de l'écosystème Go inintelligible.

@keean a écrit :

[…] pour qu'un package soit applicatif, il doit être pur (c'est-à-dire qu'il n'y a pas de variables mutables au niveau du package)

Et aucune fonction impure ne peut être employée pour initialiser des variables immuables.

@egonelbre a écrit :

Donc, oui, vous pouvez utiliser un package paramétré dans un autre.

Ce que j'avais apparemment à l'esprit, c'était des "paquets paramétrés de première classe" et le polymorphisme d'exécution proportionnel (alias dynamique) que @keean a mentionné par la suite, car je supposais que les packages paramétrés étaient proposés à la place des classes de type ou de la POO.

EDIT: mais il y a deux significations possibles pour les modules "de première classe": les modules en tant que valeurs de première classe comme dans Successor ML et MixML distingués des modules en tant que valeurs de première classe avec des types de première classe comme dans 1ML, et le compromis nécessaire dans la récursivité du module (c'est-à-dire le mélange ) entre eux.

@keean a écrit :

La solution au polymorphisme d'exécution est de créer des packages de première classe afin que les instances de signatures de packages puissent être transmises en tant qu'arguments de fonction, cela nécessite malheureusement des types dépendants (voir le travail effectué sur les types d'objets dépendants pour Scala pour éliminer le gâchis qu'ils ont créé avec leur système de type d'origine).

Qu'entendez-vous par types dépendants ? (EDIT: je suppose maintenant qu'il voulait dire typage "non dépendant de la valeur", c'est-à-dire " fonctions dont le type de résultat dépend de l'argument [d'exécution?] ['s type]") Certainement pas dépendant des valeurs de par exemple int données, comme dans Idris. Je pense que vous faites référence au typage dépendant (c'est-à-dire au suivi) du type des valeurs représentant les instances de module instanciées dans la hiérarchie des appels afin que de telles fonctions polymorphes puissent être monomorphisées au moment de la compilation? Le polymorphisme d'exécution entre-t-il en raison du fait que ces types monomorphisés sont le type existentiel lié aux types dynamiques ? Les modules F-ing ont démontré que les types « dépendants » ne sont pas absolument nécessaires pour modéliser les modules ML dans le système F _ω . Ai-je trop simplifié si je présume que @rossberg a reformulé le modèle de typage pour supprimer toutes les exigences de monomorphisation?

Le problème avec l'approche de package génératif est qu'il crée beaucoup de passe-partout […]
Les classes de type évitent ce passe-partout en sélectionnant implicitement la classe de type en fonction des types utilisés dans la fonction uniquement.

N'y a-t-il pas aussi un passe-partout avec des foncteurs applicatifs ML ? Il n'y a pas d'unification connue des classes de types et des foncteurs ML (modules) qui conserve la brièveté sans introduire de restrictions nécessaires pour empêcher (cf aussi ) l'anti-modularité inhérente au critère d'unicité globale des instances d'implémentation de classes de types.

Les classes de types ne peuvent implémenter chaque type que d'une seule manière et nécessitent sinon un passe-partout wrapper newtype pour surmonter la limitation. Voici un autre exemple de plusieurs façons d'implémenter un algorithme. Afaics, @keean a contourné cette limitation dans son exemple de tri de classe de types en remplaçant la sélection implicite par un Relation explicitement sélectionné en utilisant des types d'emballage data pour nommer différentes relations de manière générique sur le type de valeur, mais je doute si ces tactiques sont générales à toutes les variantes de modularité. Cependant, une solution plus généralisée (qui peut aider à améliorer le problème de modularité de l'unicité globale éventuellement combinée avec une restriction orpheline comme amélioration de la version proposée pour la résolution orpheline en employant une valeur non par défaut pour les implémentations qui pourraient être orphelines) peut être d'avoir un paramètre de type supplémentaire implicitement sur toutes les classes de type interface , qui, lorsqu'il n'est pas spécifié, utilise par défaut la correspondance implicite normale, mais lorsqu'il est spécifié (ou lorsqu'il n'est pas spécifié, il ne correspond à aucun autre ² ) sélectionne alors l'implémentation qui a la même valeur dans sa liste de valeurs personnalisées délimitées par des virgules (il s'agit donc d'une correspondance modulaire plus généralisée que de nommer une instance implement spécifique). La liste délimitée par des virgules est telle qu'une implémentation peut être différenciée dans plus d'un degré de liberté, comme si elle avait deux spécialisations orthogonales. Le spécialisé non par défaut souhaité peut être spécifié soit au niveau de la déclaration de la fonction, soit au niveau du site d'appel. Au site d'appel, par exemple f<non-default>(…) .

Alors pourquoi aurions-nous besoin de modules paramétrés si nous avons des classes de types ? Afaics uniquement pour la substitution (← lien important à cliquer) car la réutilisation des classes de types à cette fin ne convient pas dans la mesure où, par exemple, nous voulons qu'un module de package puisse s'étendre sur plusieurs fichiers et nous voulons pouvoir ouvrir implicitement le contenu de le module dans la portée sans passe-partout supplémentaire . Donc peut-être aller de l'avant avec une paramétrisation de package _syntaxique uniquement_ substitution uniquement (pas de première classe) est une première étape raisonnable qui peut traiter la généricité au niveau du module tout en restant ouvert à la compatibilité et au non-chevauchement des fonctionnalités si vous ajoutez des classes de type plus tard pour le niveau de la fonction généricité. macros sont par exemple typées ou simplement une substitution syntaxique (alias "préprocesseur"). S'ils sont typés, les modules dupliquent la fonctionnalité des classes de types, ce qui n'est pas souhaitable à la fois du point de vue de la minimisation des paradigmes/concepts qui se chevauchent du PL et des cas potentiels d'angle dus aux interactions du chevauchement ( comme ceux lorsque l'on tente d'offrir à la fois des foncteurs ML et des classes de types ). Les modules typés sont plus modulaires car les modifications apportées à toute implémentation encapsulée dans le module qui ne modifie pas les signatures exportées ne peuvent pas rendre les consommateurs du module incompatibles (autre que le problème d'anti-modularité susmentionné des instances d'implémentation qui se chevauchent). Je suis intéressé de lire les réflexions de @keean à ce sujet.

[…] avec des exceptions pour la récursivité polymorphe et les types existentiels (qui sont essentiellement des variantes dont vous ne pouvez pas sortir, vous ne pouvez utiliser que les interfaces que la variante confirme).

Pour aider les autres lecteurs. Par "récursivité polymorphe", je pense qu'il fait référence à des types de rang supérieur, par exemple des rappels paramétrés définis au moment de l'exécution où le compilateur ne peut pas monomorphiser le corps de la fonction de rappel car il n'est pas connu au moment de la compilation. Les types existentiels sont, comme je l'ai mentionné précédemment, équivalents aux objets de trait de Rust, qui sont un moyen d'atteindre des conteneurs hétérogènes avec une liaison ultérieure dans le problème d'expression que class sous-classant l'héritage virtuel, mais pas aussi ouvert à l'extension dans l'expression Problème car les unions avec des structures de données immuables ou la copie ³ qui ont un coût de performance O(log n) .

¹ _{Qui ne nécessite pas HKT dans l'exemple ci-dessus, car SET ne nécessite pas le type elem est un paramètre de type du type générique de set , c'est-à-dire que ce n'est pas set<elem> .}

² _{Pourtant, s'il existait plus d'une implémentation non par défaut et aucune implémentation par défaut, alors la sélection serait ambiguë et le compilateur devrait générer une erreur.}

³ _{Notez que la mutation avec des structures de données immuables ne nécessite pas nécessairement de copier la totalité de la structure de données, si la structure de données est suffisamment intelligente pour isoler l'historique tel qu'une liste à liaison simple.}

L'implémentation func pick(a CollectionOfT, count uint) []T serait un bon exemple d'application de génériques (à partir de 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) {

L'approche de l'interface{} ici est compliquée.

J'ai commenté à plusieurs reprises sur ce problème que l'un des principaux problèmes de l'approche de modèle C++ est sa dépendance à la résolution de surcharge en tant que mécanisme de métaprogrammation au moment de la compilation.

Il semble que Herb Sutter soit arrivé à la même conclusion : il existe maintenant une proposition intéressante pour la programmation à la compilation en C++ .

Il a certains éléments en commun avec le package Go reflect et ma précédente proposition de fonctions de compilation dans Go .

Salut.
J'ai écrit une proposition de génériques avec des contraintes pour Go. Vous pouvez le lire ici . Peut-être peut-il être ajouté en tant que document de 15292. Il s'agit principalement de contraintes et se lit comme un amendement aux paramètres de type Taylors dans Go .
Il est conçu comme un exemple d'une manière pratique (je crois) de faire des génériques "de type sûr" dans Go, - j'espère que cela peut ajouter quelque chose à cette discussion.
Veuillez noter que même si j'ai lu (la plupart de) ce très long fil, je n'ai pas suivi tous les liens qu'il contient, donc d'autres peuvent avoir fait des suggestions similaires. Si c'est le cas, je m'excuse.

Br. Chr.

Syntaxe bikeshedding :

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

pourrait être

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

qui ressemble plus à Allez vers moi. :-)

Plusieurs éléments ici.

Une chose est de remplacer : par _ et de remplacer # par ... .
Je suppose que vous pourriez le faire si vous préférez.

Une autre chose est de remplacer constraint[T] Array par type[T] Array constraint .
Cela semblerait indiquer que les contraintes sont des types, ce qui, à mon avis, n'est pas correct. Formellement, une contrainte est un _prédicat_ sur l'ensemble de tous les types, c'est-à-dire. un mappage de l'ensemble de types à l'ensemble { true , false }.
Ou si vous préférez, vous pouvez considérer une contrainte comme simplement _un ensemble de_ types.
Ce n'est pas un type.

Br. Chr.

Pourquoi ce constraint n'est-il pas juste un interface ?

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

Une interface serait un peu plus utile comme contrainte avec la proposition suivante : #23796 qui, à son tour, donnerait également du mérite à la proposition elle-même.

De plus, si la proposition de types de somme est acceptée sous une forme quelconque (#19412), alors ceux-ci doivent être utilisés pour contraindre le type.

Bien que je croie le mot-clé de contrainte, quelque chose comme ça devrait être ajouté, afin de ne pas répéter de grandes contraintes et d'éviter les erreurs dues à la distraction.

Enfin, pour la partie bikeshedding, je pense que les contraintes devraient être listées à la fin d'une définition, pour éviter la surpopulation (la rouille semble avoir une bonne idée ici):

// 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 : Je pense que c'est un gros avantage pour go d'avoir des interfaces implémentées implicitement plutôt qu'explicitement. La proposition @surlykke dans ce commentaire est, je pense, beaucoup plus proche de l'esprit des autres syntaxes Go.

@surlykke Je m'excuse si la proposition a la réponse à l'une de ces questions.

Une utilisation des génériques consiste à autoriser les fonctions de style intégrées. Comment implémenteriez-vous le len au niveau de l'application avec cela? La disposition de la mémoire est différente pour chaque entrée autorisée, alors en quoi est-ce mieux qu'une interface ?

Le "pick" décrit précédemment a un problème similaire où l'indexation dans une carte et l'indexation dans une tranche sont différentes. Dans le cas de la carte, s'il y a eu une conversion en tranche en premier, le même code de sélection peut être utilisé, mais comment cela se fait-il ?

Les collections sont une autre utilisation :

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

Pour le cas de type collection, je ne suis pas convaincu que ce soit une grande victoire sur les génériques Go 1 car il y a des compromis de lisibilité.

Je suis d'accord que les paramètres de type doivent avoir une certaine forme de contraintes. Sinon, nous répéterons les erreurs des modèles C++. La question est de savoir jusqu'à quel point les contraintes doivent-elles être expressives ?

À une extrémité, nous pourrions simplement utiliser des interfaces. Mais comme vous l'avez souligné, de nombreux modèles utiles ne peuvent pas être capturés de cette façon.

Ensuite, il y a votre idée, et d'autres similaires, qui tentent de définir un ensemble de contraintes utiles et de fournir une nouvelle syntaxe pour les exprimer. Mis à part le problème d'ajouter encore plus de syntaxe, il n'est pas clair où s'arrêter. Comme vous le soulignez, votre proposition capture de nombreux modèles, mais en aucun cas tous.

A l'autre extrême se trouve l'idée que je propose dans cette doc . Il utilise le code Go lui-même comme langage de contrainte. Vous pouvez capturer pratiquement n'importe quelle contrainte de cette façon, et cela ne nécessite aucune nouvelle syntaxe.

@jba
C'est un peu verbeux. Peut-être que si Go avait une syntaxe lambda, ce serait un peu plus acceptable. D'un autre côté, il semble que le plus gros problème qu'il essaie de résoudre est de vérifier si un type prend en charge un opérateur quelconque. Ce serait peut-être plus facile si Go n'avait que des interfaces prédéfinies pour différents opérateurs :

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

ou quelque chose dans ce sens.

Si le problème concerne l'extension des fonctions intégrées, le problème réside peut-être dans la manière dont le langage crée les types d'adaptateur. Par exemple, le ballonnement associé à sort.Interface n'est-il pas la raison derrière https://github.com/golang/go/issues/16721 et sort.Slice ?
En regardant https://github.com/golang/go/issues/21670#issuecomment -325739411, l'idée de @Sajmani d'avoir des littéraux d'interface pourrait être l'ingrédient nécessaire pour que les paramètres de type fonctionnent facilement avec les builtins.
Regardez la définition suivante d'Iterator :

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

Si print est une fonction qui itère simplement sur une liste et imprime son contenu, l'exemple suivant utilise des littéraux d'interface pour construire une interface satisfaisante pour print .

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

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

On peut déjà le faire s'ils déclarent globalement des types dont la seule responsabilité est de satisfaire une interface. Cependant, cette conversion d'une fonction en une méthode rend les interfaces (et donc les "contraintes") plus faciles à satisfaire. Nous ne polluons pas les déclarations de niveau supérieur avec des adaptateurs simples (comme "widgetsByName" dans le tri).
Les types définis par l'utilisateur peuvent évidemment également tirer parti de cette fonctionnalité, comme le montre cet exemple LinkedList :

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

@geovanisouza92 : Les contraintes telles que je les ai décrites sont plus expressives que les interfaces (champs, opérateurs). J'ai brièvement envisagé d'étendre les interfaces au lieu d'introduire des contraintes, mais je pense que ce serait un changement beaucoup trop intrusif pour un élément existant de Go.

@pciet Je ne suis pas tout à fait sûr de ce que vous entendez par "niveau d'application". Go a une fonction len intégrée qui peut être appliquée à un tableau, un pointeur vers un tableau, une tranche, une chaîne et un canal, donc, dans ma proposition, si un paramètre de type est contraint d'avoir l'un de ceux-ci comme type sous-jacent , len peut lui être appliqué.

@pciet À propos de votre exemple avec contrainte/interface Comparable . Notez que si vous définissez (la variante d'interface) :

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

Ensuite, vous pouvez mettre tout ce qui implémente Comparable dans Set . Comparez cela à :

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

où vous ne pouvez mettre que des valeurs de type Foo dans FooSet . C'est une sécurité de type plus forte.

@urandom Encore une fois, je ne suis pas fan de :

type MyConstraint constraint {....}

car je ne crois pas qu'une contrainte soit un type. De plus, je n'autoriserais certainement pas :

var myVar MyConstraint

qui n'a aucun sens pour moi. Une autre indication que les contraintes ne sont pas des types.

@urandom On bikeshedding: Je pense que les contraintes doivent être déclarées juste à côté des paramètres de type. Considérons une fonction ordinaire, définie comme ceci :

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

Vous ne pouviez pas lire ceci de gauche à droite. Au lieu de cela, vous devez d'abord lire func MyFunc(i) pour déterminer qu'il s'agit d'une définition de fonction. Ensuite, vous devrez sauter à la fin pour comprendre ce qu'est i , puis revenir au corps de la fonction. Pas idéal, OMI. Et je ne vois pas en quoi les définitions génériques devraient être différentes.
Mais évidemment, cette discussion est orthogonale à celle de savoir si Go devrait avoir des contraintes ou des génériques.

@surlykke
Je suis d'accord pour que ce ne soit pas un type. La chose la plus importante est qu'ils aient un nom afin qu'ils puissent être référencés par plusieurs types.

Pour les fonctions, si nous suivons la syntaxe de rust, ce serait :

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

Ainsi, il ne cachera pas des choses comme le nom de la fonction ou ses paramètres, et vous n'aurez pas besoin d'aller à la fin du corps de la fonction pour voir quelle est la contrainte sur les types génériques.

@surlykke pour la postérité, pourriez-vous localiser où votre proposition pourrait être ajoutée :
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

C'est un endroit idéal pour "compiler" toutes les propositions.

Une autre question que je vous pose à tous est de savoir comment traiter la spécialisation de différentes instanciations d'un type générique. Dans la proposition type-params , la façon de le faire est de générer la même fonction basée sur un modèle pour chaque type instancié, en remplaçant le paramètre de type par le nom du type. Afin d'avoir des fonctionnalités distinctes pour différents types, effectuez un changement de type sur le paramètre de type.

Est-il prudent de supposer que lorsque le compilateur voit un changement de type sur un paramètre de type, il est autorisé à générer une implémentation distincte pour chaque assertion ? Ou est-ce trop impliqué dans une optimisation, puisque les paramètres de type imbriqués dans les structures affirmées peuvent créer un aspect paramétrique à la génération de code ?

Dans la proposition de fonctions au moment de la compilation , comme nous savons que ces déclarations sont générées au moment de la compilation, un changement de type ne pose aucun coût d'exécution.

Un scénario pratique : si nous considérons un cas du package math/bits , effectuer une assertion de type pour appeler OnesCount pour chaque uintXX dépasserait le point d'avoir une bibliothèque de manipulation de bits efficace. Si toutefois, les assertions de type étaient transformées en ce qui suit

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

Un appel à

var x uint8 = 255
bits.OnesCount(x)

appellerait alors la fonction générée suivante (le nom n'est pas important ici):

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

@jba C'est une proposition intéressante, mais pour moi, cela souligne surtout le fait que la définition de la fonction paramétrique elle-même suffit généralement à définir ses contraintes.

Si vous allez utiliser des « opérateurs utilisés dans une fonction » comme contraintes, alors quel avantage cela vous rapporte-t-il d'écrire une seconde fonction contenant un sous-ensemble des opérateurs utilisés dans la première ?

@bcmills L'un d'eux est une spécification et l'autre est l'implémentation. C'est le même avantage que le typage statique : vous pouvez détecter les erreurs plus tôt.

Si l'implémentation est la spécification, à la manière des modèles C++, alors toute modification de l'implémentation casse potentiellement les dépendances. Cela ne peut être découvert que bien plus tard, lorsque les dépendants se recompilent et que les découvreurs n'ont aucun contexte pour comprendre le message d'erreur. Avec la spécification dans le même package, vous pouvez détecter la casse localement.

@mandolyte Je ne sais pas trop où l'ajouter - peut-être un paragraphe sous "Approches génériques" nommé "Génériques avec contraintes" ?
Le document ne semble pas contenir grand-chose sur la contrainte des paramètres de type, donc si vous ajoutiez un paragraphe où ma proposition serait mentionnée, d'autres approches des contraintes pourraient également y être répertoriées.

@surlykke l'approche générale sur le document est de faire un changement ce qui semble juste et j'essaierai de l'accepter, de l'incorporer et de l'organiser avec le reste du document. J'ai ajouté une section ici . N'hésitez pas à ajouter des choses que j'ai ratées.

@egonelbre C'est très gentil. Merci!

@jba
J'aime votre proposition, mais je pense que c'est beaucoup trop lourd pour golang. Cela me rappelle beaucoup de modèles en c++. Je pense que le principal problème est que vous pouvez écrire du code très complexe avec.
Décider si deux instances d'interface génériques se chevauchent parce que l'ensemble contraint de types se chevauchent serait une tâche difficile entraînant des temps de compilation plus lents. Idem pour la génération de code.

Je pense que les contraintes proposées sont plus légères pour aller. D'après ce que j'ai entendu, les contraintes, c'est-à-dire les classes de types, pourraient être implémentées orthogonalement au système de types d'un langage.

Je suis tout à fait d'accord sur le fait que nous ne devrions pas utiliser de contraintes implicites du corps de la fonction. Ils sont largement considérés comme l'un des défauts les plus importants des modèles C++ :

• Les contraintes ne sont pas facilement visibles. Bien que godoc puisse théoriquement énumérer toutes les contraintes dans la documentation, elles ne sont pas visibles dans le code source, sauf implicitement.
• Pour cette raison, il est possible d'inclure accidentellement une contrainte supplémentaire qui n'est visible que lorsque vous essayez d'utiliser la fonction d'une manière inattendue. En exigeant une spécification explicite des contraintes, le programmeur doit savoir exactement quelles contraintes il introduit.
• Il rend la décision sur les types de contraintes autorisées beaucoup plus ad hoc. Par exemple, suis-je autorisé à définir la fonction suivante ? Quelles sont les contraintes réelles sur T, U et V ici ? Si nous demandons au programmeur de spécifier explicitement les contraintes, alors nous sommes conservateurs dans le type de contraintes que nous autorisons (nous permettant de développer cela lentement et délibérément). Si nous essayons quand même d'être conservateurs, comment pouvons-nous donner un message d'erreur pour une fonction comme celle-ci ? "Erreur : impossible d'affecter uv() à T car il impose une contrainte illégale" ?

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

• L'appel de fonctions génériques dans d'autres fonctions génériques aggrave les situations ci-dessus, car vous devez maintenant examiner toutes les contraintes des appelés afin de comprendre les contraintes de la fonction que vous écrivez ou lisez.
• Le débogage peut être très difficile, car les messages d'erreur doivent soit ne pas fournir suffisamment d'informations pour trouver la source de la contrainte, soit ils doivent divulguer des détails internes de la fonction. Par exemple, si F a une exigence sur un type T et que l'auteur de F essaie de comprendre d'où vient cette exigence, il aimerait que le compilateur avertissez-les de la déclaration exacte qui donne lieu à la contrainte (surtout si elle provient d'un appelé générique). Mais un utilisateur de F ne veut pas cette information et, en effet, si elle est incluse dans les messages d'erreur, alors nous divulguons des détails d'implémentation de F dans les messages d'erreur de ses utilisateurs, ce qui sont une expérience utilisateur terrible.

@alercah

Par exemple, suis-je autorisé à définir la fonction suivante ?

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

Non u.v(V) est une erreur de syntaxe car V est un type et la variable t n'est pas utilisée.

Cependant, vous pourriez définir cette fonction, qui peut être celle que vous vouliez :

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

Quelles sont les contraintes réelles sur T, U et V ici ?

• Le type V n'est pas contraint.
• Le type U doit avoir une méthode v qui accepte un seul paramètre ou varargs d'un certain type assignable à partir de V , car u.v est invoqué avec un seul argument de type V .
  
  
  
  • U.v pourrait être un champ de type fonction, mais cela devrait sans doute impliquer une méthode ; voir #23796.
  
  
• Le type renvoyé par U.v doit être numérique, car la constante 1 lui est ajoutée.
• Le type de retour de U.v doit être assignable à T , car u.v(…) + 1 est assigné à une variable de type T .
• Le type T doit être numérique, car le type de retour de U.v est numérique et attribuable à T .

(Un aparté : vous pourriez dire que U et V devraient avoir la contrainte "copiable" parce que les arguments de ces types sont passés par valeur, mais le système de type non générique existant n'applique pas cette contrainte non plus. Cela fait l'objet d'une proposition distincte.)

Si nous demandons au programmeur de spécifier explicitement les contraintes, alors nous sommes conservateurs dans le type de contraintes que nous autorisons (nous permettant de développer cela lentement et délibérément).

Oui, c'est vrai : mais omettre une contrainte serait un grave défaut, que ces contraintes soient implicites ou non. Selon l'OMI, le rôle le plus important des contraintes est de résoudre l'ambiguïté. Par exemple, dans les contraintes ci-dessus, le compilateur doit être prêt à instancier u.v en tant que méthode à argument unique ou variadique.

L'ambiguïté la plus intéressante se produit pour les littéraux, où nous devons lever l'ambiguïté entre les types struct et les types composites :

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

Si nous essayons quand même d'être conservateurs, comment pouvons-nous donner un message d'erreur pour une fonction comme celle-ci ? "Erreur : impossible d'affecter uv() à T car il impose une contrainte illégale" ?

Je ne suis pas tout à fait sûr de ce que vous demandez, car je ne vois pas de contraintes conflictuelles pour cet exemple. Qu'entendez-vous par « contrainte illégale » ?

Le débogage peut être très difficile, car les messages d'erreur doivent soit ne pas fournir suffisamment d'informations pour trouver la source de la contrainte, soit ils doivent divulguer des détails internes de la fonction.

Toutes les contraintes pertinentes ne peuvent pas être exprimées par le système de type (voir aussi https://github.com/golang/go/issues/22876#issuecomment-347035323). Certaines contraintes sont appliquées par des paniques d'exécution ; certains sont appliqués par le détecteur de course ; les contraintes les plus dangereuses sont simplement documentées et pas du tout détectées.

Tous ces "détails internes qui fuient" dans une certaine mesure. (Voir aussi https://xkcd.com/1172/.)

Par exemple, si […] l'auteur de F essaie de comprendre d'où vient cette exigence, il aimerait que le compilateur l'alerte sur la déclaration exacte qui donne lieu à la contrainte (surtout si elle provient d'un appelé générique). Mais un utilisateur de F ne veut pas cette information[.]

Peut-être? C'est ainsi que les auteurs d'API utilisent les annotations de type dans les langages inférés par type tels que Haskell et ML, mais cela conduit également à un terrier de lapin de types profondément paramétriques ("d'ordre supérieur") en général.

Par exemple, supposons que vous ayez cette fonction :

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

Comment exprimez-vous les contraintes explicites sur le type Arg ? Ils dépendent de l'instanciation spécifique de F . Ce type de dépendance semble manquer dans de nombreuses propositions récentes de contraintes.

Non. uv(V) est une erreur de syntaxe car V est un type et la variable t est inutilisée.

Cependant, vous pourriez définir cette fonction, qui peut être celle que vous vouliez :

Oui, c'était l'intention, mes excuses.

Le type T doit être numérique, car le type de retour de U.v est numérique et attribuable à T .

Doit-on vraiment considérer cela comme une contrainte ? C'est déductible des autres contraintes, mais est-il plus ou moins utile d'appeler cela une contrainte distincte ? Les contraintes implicites posent cette question d'une manière que les contraintes explicites ne posent pas.

Oui, c'est vrai : mais omettre une contrainte serait un grave défaut, que ces contraintes soient implicites ou non. Selon l'OMI, le rôle le plus important des contraintes est de résoudre l'ambiguïté. Par exemple, dans les contraintes ci-dessus, le compilateur doit être prêt à instancier uv en tant que méthode à argument unique ou variadique.

Je voulais dire "contraintes que nous autorisons" comme dans le langage. Avec des contraintes explicites, il est beaucoup plus facile pour nous de décider quel type de contraintes nous sommes prêts à autoriser les utilisateurs à écrire, plutôt que de simplement dire que la contrainte est "tout ce qui fait compiler les choses". Par exemple, mon exemple Foo ci-dessus implique en fait un type supplémentaire implicite distinct de T , U ou V , puisque nous devons considérer le type de retour de u.v . Ce type n'est pas explicitement mentionné de quelque manière que ce soit dans la déclaration de f ; les propriétés qu'il doit avoir sont complètement implicites. De même, sommes-nous disposés à autoriser les types de rang supérieur ( forall ) ? Je ne peux pas trouver d'exemple du haut de ma tête, mais je ne peux pas non plus me convaincre que vous ne pouvez pas implicitement écrire une liaison de type de rang supérieur.

Un autre exemple est de savoir si nous devons autoriser une fonction à tirer parti d'une syntaxe surchargée. Si une fonction implicitement contrainte fait for i := range t pour certains t de type générique T , la syntaxe fonctionne si T est un tableau, une tranche, un canal, ou carte. Mais la sémantique est assez différente, surtout si T est un type de canal. Par exemple, si t == nil (ce qui peut arriver tant que T est un tableau), alors l'itération ne fait rien, car il n'y a pas d'éléments dans une tranche ou une carte nulle, ou bloque pour toujours puisque c'est ce que font les chaînes nil . C'est un gros footgun qui attend d'arriver. De même fait m[i] = ... ; si j'ai l'intention que m soit une carte, je devrai me prémunir contre le fait qu'il s'agisse d'une tranche car le code pourrait paniquer sur une affectation hors plage sinon.

En fait, je pense que cela se prête à un autre argument contre les contraintes implicites : les auteurs d'API peuvent écrire des déclarations artificielles juste pour ajouter des contraintes. Par exemple, for _, _ := range t { break } empêche un canal tout en autorisant les cartes, les tranches et les tableaux ; x = append(x) force x à avoir le type tranche. var _ = make(T, 0) autorise les tranches, les cartes et les canaux, mais pas les tableaux. Il y aura un livre de recettes expliquant comment ajouter implicitement des contraintes afin que quelqu'un ne puisse pas appeler votre fonction avec un type pour lequel vous n'avez pas écrit de code correct. Je ne peux même pas penser à un moyen d'écrire du code qui ne compile que pour les types de carte, à moins que je ne connaisse également le type de clé. Et je ne pense pas que ce soit hypothétique du tout; les cartes et les tranches se comportent assez différemment pour la plupart des applications

Je ne suis pas tout à fait sûr de ce que vous demandez, car je ne vois pas de contraintes conflictuelles pour cet exemple. Qu'entendez-vous par « contrainte illégale » ?

Je veux dire une contrainte qui n'est pas autorisée par le langage, comme si le langage décide d'interdire les contraintes de rang supérieur.

Toutes les contraintes pertinentes ne peuvent pas être exprimées par le système de type (voir aussi #22876 (commentaire)). Certaines contraintes sont appliquées par des paniques d'exécution ; certains sont appliqués par le détecteur de course ; les contraintes les plus dangereuses sont simplement documentées et pas du tout détectées.

Tous ces "détails internes qui fuient" dans une certaine mesure. (Voir aussi https://xkcd.com/1172/.)

Je ne vois pas vraiment en quoi #22876 entre en jeu ; qui essaie d'utiliser le système de type pour exprimer un autre type de contrainte. Il sera toujours vrai que nous ne pouvons pas exprimer certaines contraintes sur des valeurs, ou sur des programmes, même avec un système de types de complexité arbitraire. Mais nous ne parlons ici que des contraintes sur les types . Le compilateur doit pouvoir répondre à la question "Puis-je instancier ce générique avec le type T ?" ce qui signifie qu'il doit comprendre les contraintes, qu'elles soient implicites ou explicites. (Notez que certains langages, comme C++ et Rust, ne peuvent pas trancher cette question en général parce qu'elle peut dépendre d'un calcul arbitraire et revient donc au problème d'arrêt, mais ils expriment toujours les contraintes qui doivent être satisfaites.)

Ce que je veux dire ressemble plus à "quel message d'erreur l'exemple suivant devrait-il donner?"

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

Nous pouvons dire Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() . Ce message d'erreur est utile pour un utilisateur de IndirectlyConstrained , car il définit clairement les contraintes manquantes. Mais il ne fournit aucune information à quelqu'un essayant de déboguer pourquoi IndirectlyConstrained a cette contrainte, ce qui est un gros problème d'utilisabilité s'il s'agit d'une fonction volumineuse. Nous pourrions ajouter Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N , mais maintenant nous divulguons des détails sur l'implémentation de IndirectlyConstrained . De plus, nous n'avons pas expliqué pourquoi IndirectlyConstrained a la contrainte, alors ajoutons-nous un autre Note: this constraint exists on U because DirectlyConstrained calls t.DoSomething() on line M ? Que se passe-t-il si la contrainte implicite provient d'un appelé quatre niveaux plus bas dans la pile des appels ?

De plus, comment formatons-nous ces messages d'erreur pour les types qui ne sont pas explicitement répertoriés en tant que paramètres ? Par exemple, si dans l'exemple ci-dessus, IndirectlyConstrained appelle DirectlyConstrained(t.U()) . Comment se réfère-t-on même au type? Dans ce cas, nous pourrions dire the type of t.U() , mais la valeur ne sera pas nécessairement le résultat d'une seule expression ; il pourrait être construit sur plusieurs déclarations. Ensuite, nous aurions soit besoin de synthétiser une expression avec les types corrects à mettre dans le message d'erreur, une expression qui n'apparaît jamais dans le code, soit nous aurions besoin de trouver un autre moyen de s'y référer qui serait moins clair pour le pauvre appelant qui a violé la contrainte.

Comment exprimez-vous les contraintes explicites sur le type Arg ? Elles dépendent de l'instanciation spécifique de F. Ce type de dépendance semble manquer dans de nombreuses propositions récentes de contraintes.

Déposez F et faites en sorte que le type de f soit func (Arg) Result . Oui, il ignore les fonctions variadiques, mais le reste de Go le fait aussi. Une proposition visant à rendre les varargs funcs attribuables à des signatures compatibles pourrait être faite séparément.

Pour les cas où nous avons réellement besoin de limites de type d'ordre supérieur, il peut être logique ou non de les inclure dans les génériques v1. Les contraintes explicites nous obligent à décider explicitement si nous voulons prendre en charge les types d'ordre supérieur, et comment. Le manque de considération jusqu'à présent est un symptôme, je pense, du fait que Go n'a actuellement aucun moyen de se référer aux propriétés des types intégrés. C'est une question ouverte générale de savoir comment tout système générique autorisera des fonctions génériques sur tous les types numériques, ou tous les types entiers, et la plupart des propositions ne se sont pas beaucoup concentrées sur cela.

Veuillez évaluer l'implémentation de mes génériques dans votre prochain projet
http://go-li.github.io/

Nous pouvons dire Error: cannot call IndirectlyConstrained with [T = int]; T must have a method with signature func (T t) DoSomething() . Ce message d'erreur […] ne fournit aucune information à quelqu'un essayant de déboguer pourquoi IndirectlyConstrained a cette contrainte, ce qui est un gros problème d'utilisabilité s'il s'agit d'une fonction volumineuse.

Je tiens à souligner une grande hypothèse que vous faites ici : que le message d'erreur de go build est le _seul_ outil dont dispose le programmeur pour diagnostiquer le problème.

Pour utiliser une analogie : si vous rencontrez un error au moment de l'exécution, vous disposez de plusieurs options pour le débogage. L'erreur elle-même ne contient qu'un simple message, qui peut ou non suffire à décrire l'erreur. Mais ce ne sont pas les seules informations dont vous disposez : par exemple, vous disposez également de toutes les instructions de journal émises par le programme, et s'il s'agit d'un bogue vraiment épineux, vous pouvez le charger dans un débogueur interactif.

Autrement dit, le débogage à l'exécution est un processus interactif. Alors, pourquoi devrions-nous supposer un débogage non interactif pour les erreurs de compilation⸮ Comme alternative, nous pourrions enseigner à l'outil guru les contraintes de type. Ensuite, la sortie du compilateur serait quelque chose comme :

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

Cela donne à l'utilisateur du paquet générique les informations dont il a besoin pour déboguer le site d'appel immédiat, mais donne _également_ un fil d'Ariane au responsable du paquet (et, surtout, à son environnement d'édition !) pour approfondir ses recherches.

Nous pourrions ajouter Note: this constraint exists on T because IndirectlyConstrained calls DirectlyConstrained with [U = T] on line N , mais maintenant nous divulguons des détails sur l'implémentation de IndirectlyConstrained .

Oui, c'est ce que je veux dire à propos des fuites d'informations de toute façon. Vous pouvez déjà utiliser guru describe pour jeter un coup d'œil à l'intérieur d'une implémentation. Vous pouvez jeter un coup d'œil à l'intérieur d'un programme en cours d'exécution à l'aide d'un débogueur, et non seulement rechercher la pile, mais également descendre dans des fonctions arbitrairement de bas niveau.

Je suis tout à fait d'accord que nous devrions cacher les informations probablement non pertinentes _par défaut_, mais cela ne signifie pas que nous devons les cacher dans l'absolu.

Si une fonction implicitement contrainte fait pour i := range t pour certains t de type générique T , la syntaxe fonctionne si T est n'importe quel tableau, tranche, canal , ou carte. Mais la sémantique est assez différente, surtout si T est un type de canal.

Je pense que c'est l'argument le plus convaincant pour les contraintes de type, mais cela ne nécessite pas que les contraintes explicites soient aussi détaillées que ce que certains proposent. Pour lever l'ambiguïté des sites d'appel, il semble suffisant de contraindre les paramètres de type par quelque chose de plus proche de reflect.Kind . Nous n'avons pas besoin de décrire des opérations qui sont déjà claires dans le code ; à la place, nous n'avons qu'à dire des choses comme « T est un type de tranche ». Cela conduit à un ensemble de contraintes beaucoup plus simple :

• un type soumis à des opérations d'index doit être étiqueté comme linéaire ou associatif,
• un type soumis à des opérations range doit être étiqueté comme nil-empty ou nil-blocking,
• un type avec des littéraux doit être étiqueté comme ayant des champs ou des indices, et
• (peut-être) un type avec des opérations numériques doit être étiqueté comme virgule fixe ou flottante.

Cela conduit à un langage de contraintes beaucoup plus étroit, peut-être quelque chose comme :

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

avec des exemples comme :

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

Je pense que nous avons fait un grand pas vers le générique personnalisé en introduisant un alias de type.
L'alias de type rend les super types (type de types) possibles.
Nous pouvons traiter les types comme des valeurs en utilisant.

Pour simplifier les explications, nous pouvons ajouter un nouvel élément de code, genre .
La relation entre les genres et les types est comme la relation entre les types et les valeurs.
En d'autres termes, un genre signifie un type de types.

Chaque genre de type, à l'exception des genres struct et interface et function, correspond à un genre prédéclaré.

• Bool
• Chaîne de caractères
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint, Uintptr
• Float32, Float64
• Complexe64, Complexe128
• Tableau, Tranche, Carte, Canal, Pointeur, UnsafePointer

Il existe d'autres genres prédéclarés, tels que Comaprable, Numeric, Inger, Float, Complex, Container, etc. Nous pouvons utiliser Type ou * désigner le genre de tous les types.

Les noms de tous les genres intégrés commencent tous par une lettre majuscule.

Chaque type de structure et d'interface et de fonction correspond à un genre.

Nous pouvons également déclarer des genres personnalisés :

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

Pour rendre l'explication suivante cohérente, un modificateur de genre est nécessaire.
Le modificateur de genre est noté Const . Par example:

• Const Integer est un genre (différent de Integer ) et son instance doit être une valeur constante dont le type doit être un entier. Cependant, la valeur constante peut être considérée comme un type spécial.
• Const func(int) bool est un genre (différent de func(int) bool ) et son instance doit être une valeur de fonction déclarée. Cependant, la déclaration de fonction peut être considérée comme un type spécial.

(La solution du modificateur est délicate, il existe peut-être d'autres meilleures solutions de conception.)

Bon, continuons.
Nous avons besoin d'un autre concept. Trouver un bon nom pour ce n'est pas facile,
Appelons-le simplement crate .
Généralement, la relation entre les caisses et les genres est comme la relation entre les fonctions et les types.
Un crate peut prendre des types comme paramètres et des types de retour.

Une déclaration de caisse (en supposant que le code suivant est déclaré dans le package lib ) :

crate Example [T Float, S {width, height T}, N Const Integer] [*, *, *] {
    type MyArray [N]T

    func Add(a, b T) T {
        return a+b
    }

    type M struct {
        x T
        y S
    }

    func (m *M) Area() T {
        m.DoSomthing()
        return m.y.width * m.y.height
    }

    func (m *M) Perimeter() T {
        return 2 * Add(m.y.width, m.y.height)
    }

    export M, Add, MyArray
}

Utilisation de la caisse ci-dessus.

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

Mes idées absorbent de nombreuses idées d'autres personnes présentées ci-dessus.
Ils ne sont pas vraiment mûrs maintenant.
Je les poste ici juste parce que je sens qu'ils sont intéressants,
et je ne veux plus l'améliorer.
Tant de cellules cérébrales ont été tuées en réparant les trous dans les idées.
J'espère que ces idées pourront apporter des inspirations à d'autres gophers.

Ce que vous appelez "genre" s'appelle en fait "genre", et est bien connu dans le
communauté de programmation fonctionnelle. Ce que vous appelez une caisse est un objet restreint
sorte de foncteur ML.

Le mercredi 4 avril 2018 à 12 h 41, dotaheor [email protected] a écrit :

Je pense que nous avons fait un grand pas vers le générique personnalisé en introduisant
alias de type.
L'alias de type rend les super types (type de types) possibles.
Nous pouvons traiter les types comme des valeurs en utilisant.

Pour simplifier les explications, nous pouvons ajouter un nouvel élément de code, genre.
La relation entre les genres et les types est comme la relation entre les types
et valeurs.
En d'autres termes, un genre signifie un type de types.

Chaque type de type, à l'exception des types de structure et d'interface et de fonction,
correspond à un genre pré-déclaré.

• Bool
• Chaîne de caractères
• Int8, Uint8, Int16, Uint16, Int32, Uint32, Int64, Uint64, Int, Uint,
  Uintptr
  & Float32, Float64
• Complexe64, Complexe128
• Tableau, Tranche, Carte, Canal, Pointeur, UnsafePointer

Il existe d'autres genres prédéclarés, tels que Comaprable, Numeric,
Entier, Flottant, Complexe, Conteneur, etc. Nous pouvons utiliser Type ou * indique
le genre de tous les types.

Les noms de tous les genres intégrés commencent tous par une lettre majuscule.

Chaque type de structure et d'interface et de fonction correspond à un genre.

Nous pouvons également déclarer des genres personnalisés :

genre Addable = Numérique | Chaîne de caractères
genre Ordonnable = Entier | Flotteur | Chaîne de caractères
genre Validator = func(int) bool // chaque paramètre et type de résultat doit être un type spécifié.
genre HaveFieldsAndMethods = {
width int // nous devons utiliser un type spécifique pour définir les champs.
height int // nous ne pouvons pas utiliser de genre pour définir les champs.
Load(v []byte) error // chaque paramètre et type de résultat doit être un type spécifié.
FaireQuelqueChose()
}
genre GenreFromStruct = aStructType // déclare un genre à partir d'un type struct
genre GenreFromInterface = anInterfaceType // déclare un genre à partir d'un type d'interface
genre GenreFromStructInterface = aStructType | unTypeInterface

Pour rendre l'explication suivante cohérente, un modificateur de genre est nécessaire.
Le modificateur de genre est noté Const. Par example:

• Const Integer est un genre et son instance doit être une valeur constante
  dont le type doit être un entier.
  Cependant, la valeur constante peut être considérée comme un type spécial.
• Const func(int) bool est un genre et son instance doit être un delcared
  valeur de la fonction.
  Cependant, la déclaration de fonction peut être considérée comme un type spécial.

(La solution du modificateur est délicate, il existe peut-être une autre meilleure conception
solutions.)

Bon, continuons.
Nous avons besoin d'un autre concept. Trouver un bon nom pour ce n'est pas facile,
Appelons ça caisse.
Généralement, la relation entre les caisses et les genres est comme la relation
entre les fonctions et les types.
Un crate peut prendre des types comme paramètres et des types de retour.

Une déclaration de caisse (en supposant que le code suivant est déclaré dans lib
paquet):

caisse Exemple [T Float, S {largeur, hauteur T}, N Const Entier] [*, *, *] {
tapez MonTableau [N]T

fonction Ajouter(a, b T) T {
retour a+b
}

// Un genre de portée de caisse. Ne peut être utilisé que dans la caisse.

// M est un type de genre G
structure de type M {
x T
y S
}

func (m *M) Aire() T {
m.FaireQuelqueChose()
retourner malargeur * mahauteur
}

func (m *M) Périmètre() T {
return 2 * Ajouter(malargeur, mahauteur)
}

exporter M, ajouter, MyArray
}

Utilisation de la caisse ci-dessus.

importer "lib"

// Nous pouvons utiliser AddFunc comme une fonction delcared normale.
type Rect, AddFunc, Array = lib.Example(float32, struct{x, y float32})

func demo() {
var r Rect
a, p = r.Aire(), r.Périmètre()
_ = AddFunc(a, p)
}

Mes idées absorbent de nombreuses idées d'autres personnes présentées ci-dessus.
Ils ne sont pas vraiment mûrs maintenant.
Je les poste ici juste parce que je sens qu'ils sont intéressants,
et je ne veux plus l'améliorer.
Tant de cellules cérébrales ont été tuées en réparant les trous dans les idées.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment-378665695 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AGGWB78BrjN0BxRfroH-jRNy4mCXgSwCks5tlPfMgaJpZM4IG-xv
.

J'ai l'impression qu'il y a des différences entre Kind et Genre.

Au fait, si un crate ne renvoie qu'un seul type, nous pouvons utiliser son appel comme type directement.

package lib

// export a type
crate List [T *] * {
    type List struct {
        ...
    }

    export List
}

utilise le:

import "lib"

var l lib.List[int]

Il y aurait des règles de "déduction de genre", tout comme la "déduction de type" dans le système actuel.

@dotaheor , @DemiMarie a raison. Votre concept de "genre" ressemble exactement au "genre" de la théorie des types. (Votre proposition nécessite une règle de sous-type, mais ce n'est pas rare.)

Le mot-clé genre de votre proposition définit les nouveaux genres comme des super-genres de genres existants. Le mot-clé crate définit les objets avec des "signatures de caisse", qui sont un genre qui n'est pas un sous-genre de Type .

En tant que système formel, votre proposition ressemble à quelque chose comme :

Caisse ::= χ | ⋯
Tapez ::= τ | χ | int | bool | ⋯ | func(τ) | func(τ) τ | []τ | χ[τ₁, …]

CaisseSig ::= [κ₁, …] ⇒ [κₙ, …]
Genre ::= κ | exactly τ | kindOf κ | Map | Chan | ⋯ | Const κ | Type | CaisseSig

Pour abuser de la notation de la théorie des types :

• Lire "⊢" comme "implique".
• Lisez « k1 ⊑ k2 » comme « k1 est un sous-type de k2 ».
• Lisez ":" comme "est de la sorte".

Ensuite, les règles ressemblent à quelque chose comme :

⊢ τ : exactly τ
⊢ exactly τ ⊑ kindOf exactly τ
⊢ kindOf exactly τ ⊑ Type

τ : κ₁ ∧ κ₁ ⊑ κ₂ ⊢ τ : κ₂

τ₁ : Type ∧ τ₂ : Type ⊢ kindOf exactly map[τ₁]τ₂ ⊑ Map
⊢ Map ⊑ Type

κ₁ ⊑ κ₂ ⊢ Const κ₁ ⊑ Const κ₂

[…]
(Et ainsi de suite, pour tous les types intégrés)

Les définitions de type confèrent des genres, et les genres sous-jacents se réduisent aux genres des types intégrés :

type τ₁ τ₂ ∧ τ₂ : κ ⊢ τ₁ : kindOf κ

⊢ kindOf kindOf κ ⊑ kindOf κ
⊢ kindOf Map ⊑ Map
[…]

genre définit de nouvelles relations de sous-type :
genre κ = κ₁ | κ₂ ⊢ κ₁ ⊑ κ
genre κ = κ₁ | κ₂ ⊢ κ₂ ⊑ κ

(Vous pouvez définir Numeric et autres en termes de | .)

genre κ = κ₁ & κ₂ ∧ ( κ₃ ⊑ κ₁ ) ∧ ( κ₃ ⊑ κ₂ ) ⊢ κ₃ ⊑ κ

La règle d'expansion de caisse est similaire :
type τₙ, … = χ[τ₁, …] ∧ ( χ : [κ₁, …] ⇒ [κₙ, …] ) ∧ ( τ₁ : κ₁ ) ∧ ⋯ ⊢ τₙ : κₙ

Tout cela ne parle que des types, bien sûr. Si vous voulez en faire un système de type, vous avez également besoin de règles de type. 🙂

Donc, ce que vous décrivez est une forme assez bien comprise de paramétricité. C'est bien, dans la mesure où c'est bien compris, mais décevant dans la mesure où cela n'aide pas à résoudre les problèmes uniques que Go introduit.

Les problèmes vraiment intéressants et noueux que Go introduit concernent principalement l'inspection de type dynamique. Comment les paramètres de type doivent-ils interagir avec les assertions de type et la réflexion ?

(Par exemple, devrait-il être possible de définir des interfaces avec des méthodes de types paramétriques ? Si oui, que se passe-t-il si vous tapez une valeur de cette interface avec un nouveau paramètre au moment de l'exécution ?)

Sur une note connexe, y a-t-il eu une discussion sur la façon de rendre le code générique plutôt que les types intégrés et définis par l'utilisateur ? Comme faire du code qui peut gérer les bigints et les entiers primitifs ?

Sur une note connexe, y a-t-il eu une discussion sur la façon de rendre le code générique plutôt que les types intégrés et définis par l'utilisateur ? Comme faire du code qui peut gérer les bigints et les entiers primitifs ?

Les mécanismes basés sur les classes de type, comme dans Genus et Familia, peuvent le faire efficacement. Consultez notre article PLDI 2015 pour plus de détails.

@DemiMarie
Je pense que "genre" == "ensemble de traits".

[Éditer]
Peut-être que traits est un meilleur mot clé.
Nous pouvons voir que chaque type est également un ensemble de traits.

La plupart des traits sont définis pour un seul type.
Mais un trait plus complexe peut définir une relation entre deux types.

[modifier 2]
supposons qu'il existe deux ensembles de traits A et B, nous pouvons effectuer les opérations suivantes :

A + B: union set
A - B: difference set
A & B: intersection set

L'ensemble de traits d'un type d'argument doit être un super ensemble du genre de paramètre correspondant (un ensemble de traits).
L'ensemble de caractéristiques d'un type de résultat doit être un sous-ensemble du genre de résultat correspondant (un ensemble de caractéristiques).

(A MON HUMBLE AVIS)

Pourtant, je pense que la reliure des alias de type est la voie à suivre pour ajouter des génériques à Go. Il n'a pas besoin d'un énorme changement dans la langue. Les packages généralisés de cette manière peuvent toujours être utilisés dans Go 1.x. Et il n'est pas nécessaire d'ajouter des contraintes car il est possible de le faire en définissant le type par défaut pour l'alias de type, sur quelque chose qui remplit déjà ces contraintes. Et l'aspect le plus important des alias de type de reliaison est que les types composites intégrés (tranches, cartes et canaux) n'ont pas besoin d'être modifiés et généralisés.

@dc0d

Comment les alias de type devraient-ils remplacer les génériques ?

@sighoya Rebinding Type Aliases peut remplacer les génériques (pas seulement les alias de type). Supposons qu'un package introduit des alias de type au niveau du package comme :

package likedlist

type T = interface{}

type LinkedList struct {
    // ...
}

Si Type Alias ​​Rebinding (et les fonctionnalités du compilateur) sont fournis, il est alors possible d'utiliser ce package pour créer des listes chaînées pour différents types concrets, au lieu d'une interface vide :

package main

import (
    "likedlist"
)

type intLL = likedlist.LinkedList(likedlist.T = int)
type stringLL = likedlist.LinkedList(likedlist.T = string)

func main() {}

Si nous utilisons l'alias en tant que tel, la méthode suivante est plus propre.

// 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 et comment cela serait-il mis en œuvre ? Le code est sympa mais il ne dit rien sur la façon dont il fonctionne réellement à l'intérieur. Et, en regardant l'histoire des propositions de génériques, pour Go c'est très important, pas seulement son apparence et sa sensation.

@dotaheor C'est incompatible avec Go 1.x.

@creker J'ai implémenté un outil (nommé goreuse ) qui utilise cette technique pour générer du code et né comme un concept pour Type Alias ​​Rebinding.

Il peut être trouvé ici . Il y a une vidéo de 15 minutes qui explique l'outil.

@dc0d donc cela fonctionne un peu comme des modèles C++ générant des implémentations spécialisées. Je ne pense pas que cela serait accepté car l'équipe Go (et, franchement, moi et beaucoup d'autres personnes ici) semble être contre tout ce qui ressemble aux modèles C++. Il augmente les binaires, ralentit la compilation, ne serait peut-être pas en mesure de produire des erreurs significatives. Et, en plus de cela, n'est pas compatible avec les packages binaires uniquement que Go prend en charge. C'est pourquoi C++ a choisi d'écrire des modèles dans les fichiers d'en-tête.

@creker

cela fonctionne donc un peu comme les modèles C++ générant des implémentations spécialisées pour chaque type utilisé.

Je ne sais pas (Cela fait environ 16 ans que je n'ai pas écrit de C++). Mais d'après votre explication, cela semble être le cas. Pourtant, je ne sais pas si ou comment ils sont les mêmes.

Je ne pense pas que cela serait accepté car l'équipe Go (et, franchement, moi et beaucoup d'autres personnes ici) semble être contre tout ce qui ressemble aux modèles C++.

Bien sûr, tout le monde ici a de bonnes raisons pour ses préférences en fonction de ses priorités. Le premier sur ma liste est la compatibilité avec Go 1.x.

Il augmente les binaires,

Ça pourrait.

ralentit la compilation,

J'en doute fortement (comme cela peut être vécu avec goreuse ).

Et, en plus de cela, n'est pas compatible avec les packages binaires uniquement que Go prend en charge.

Je ne suis pas sûr. Est-ce que d'autres façons d'implémenter des génériques supportent cela ?

ne serait peut-être pas en mesure de produire des erreurs significatives.

Cela pourrait être un peu gênant. Pourtant, cela se produit au moment de la compilation et peut être compensé, en utilisant certains outils, dans une large mesure. De plus, si l'alias de type agissant comme paramètre de type pour le package est une interface, il peut simplement être vérifié qu'il est assignable à partir du type concret fourni. Bien que le problème pour les types primitifs comme int et string et les structures demeure.

@dc0d

J'y pense un peu.
A côté de cela, il est établi en interne sur les interfaces, le 'T' dans votre exemple

type T=interface{}

est traité comme une variable de type mutable, mais il doit être un alias vers un type spécifique, c'est-à-dire une référence const à un type.
Ce que vous voulez, c'est le type T, mais cela impliquerait l'introduction de génériques.

@sighoya Je ne suis pas sûr de comprendre ce que vous avez dit.

Il est établi en interne sur les interfaces

Pas vrai. Comme décrit dans mon commentaire d'origine, il est possible d'utiliser des types spécifiques qui remplissent une contrainte. Par exemple, l'alias de type de paramètre de type peut être déclaré comme :

type T = int

Et seuls les types qui ont l'opérateur + (ou - ou * ; cela dépend si cet opérateur est utilisé dans le corps du package) peuvent être utilisés comme valeur de type qui se trouve dans ce paramètre de type.

Il n'y a donc pas que les interfaces qui peuvent être utilisées comme espace réservé pour les paramètres de type.

mais cela impliquerait l'introduction de génériques.

Ceci _est_ un moyen d'introduire/implémenter des génériques dans le langage Go lui-même.

@dc0d

Pour fournir le polymorphisme, vous utiliserez interface{} car cela permet de définir T sur n'importe quel type ultérieurement.

Définir 'type T=Int' ne gagnerait pas grand-chose.

Si vous diriez que 'type T' est d'abord non déclaré/non défini, ce qui peut être défini plus tard, eh bien, vous avez quelque chose comme des génériques.

Le problème est que 'T' contient le module/paquet à l'échelle et n'est local à aucune fonction ou structure (d'accord, peut-être une déclaration de type imbriquée dans une structure accessible de l'extérieur).

Pourquoi ne pas écrire à la place ? :

fun<type T>(t T)

ou

fun[type T](t T)

De plus, nous avons besoin d'une machinerie d'inférence de type pour déduire les bons types lors de l'appel d'une fonction ou d'un struct générique sans spécialisation de paramètre de type au début.

@dc0d a écrit

Et seuls les types qui ont l'opérateur + (ou - ou * ; cela dépend si cet opérateur est utilisé dans le corps du package) peuvent être utilisés comme valeur de type qui se trouve dans ce paramètre de type.

Pouvez-vous en dire plus ?

@sighoya

Pour fournir le polymorphisme, vous utiliserez interface{} car cela permet de définir T sur n'importe quel type ultérieurement.

Le polymorphisme n'est pas atteint en ayant des types compatibles, lors de la reliaison des alias de type. La seule contrainte réelle est le corps du package générique. Ils doivent être compatibles mécaniquement.

Pouvez-vous en dire plus ?

Par exemple, si un alias de type de paramètre de niveau de package est défini comme :

package genericadd

type T = int

func Add(a, b T) T { return a + b }

Ensuite, pratiquement tous les types numériques peuvent être affectés à T , comme :

package main

import (
    "genericadd"
)

var add = genericadd.Add(
    T = float64
)

func main() {
    var (
        a, b float64
    )

    println(add(a, b))
}

@dc0d

Pourtant, je ne sais pas si ou comment ils sont les mêmes.

Ils sont les mêmes dans un sens où ils fonctionnent à peu près de la même manière d'après ce que je vois. Pour chaque modèle de classe, le compilateur d'instanciation générerait une implémentation unique si c'est la première fois qu'il voit l'utilisation de la combinaison particulière du modèle de classe et de sa liste de paramètres. Cela augmente la taille binaire car vous avez maintenant plusieurs implémentations du même modèle de classe. Ralentit la compilation car le compilateur devrait maintenant générer ces implémentations et effectuer toutes sortes de vérifications. Dans le cas de C++, l'augmentation du temps de compilation peut être énorme. Vos exemples de jouets sont rapides, mais ceux de C++ le sont aussi.

Je ne suis pas sûr. Est-ce que d'autres façons d'implémenter des génériques supportent cela ?

Les autres langues n'ont aucun problème avec cela. En particulier, C # comme le plus familier pour moi. Mais il utilise la génération de code d'exécution que l'équipe Go exclut complètement. Java fonctionne également mais leur implémentation n'est pas la meilleure, c'est le moins qu'on puisse dire. D'après ce que j'ai compris, certaines des propositions d'ianlancetaylor pourraient gérer uniquement des packages binaires.

La seule chose que je ne comprends pas, c'est si les packages uniquement binaires doivent être pris en charge. Je ne les vois pas explicitement mentionnés dans les propositions. Je ne m'en soucie pas vraiment, mais c'est quand même une caractéristique de la langue.

Juste pour tester ma compréhension... considérez ce dépôt d'algorithmes de copier/coller [ ici ]. Sauf si vous souhaitez utiliser "int", le code ne peut pas être utilisé directement. Il doit être copié et collé et modifié pour fonctionner. Et par modifications, je veux dire que chaque instance de "int" doit être remplacée par le type dont vous avez vraiment besoin.

L'approche d'alias de type apporterait les modifications une fois à, disons T, et insérerait une ligne "type T int". Ensuite, le compilateur aurait besoin de relier T à autre chose, disons float64.

Donc:
a) Je dirais qu'il n'y aurait pas de ralentissement du compilateur à moins que vous n'utilisiez réellement cette technique. C'est donc votre choix.
b) Étant donné le nouveau truc vgo, où plusieurs versions du même code peuvent être utilisées ... ce qui signifie qu'il doit y avoir une méthode pour cacher les sources utilisées hors de vue, alors le compilateur peut sûrement garder une trace de si deux des utilisations de la même reliure sont utilisées et évitent les doublons. Je pense donc que le gonflement du code serait le même que les techniques actuelles de copier/coller.

Il me semble qu'entre les alias de type et le vgo à venir, les bases de cette approche des génériques sont quasiment achevées...

Il y a quelques "inconnues" listées dans la proposition [ ici ]. Ce serait donc bien de le détailler un peu plus.

@mandolyte , vous pouvez ajouter un autre niveau d'indirection en enveloppant des types spécialisés dans un conteneur général. De cette façon, votre implémentation peut rester la même. Le compilateur fera alors toute la magie. Je pense que la proposition de paramètres de type de Ian fonctionne de cette façon.

Je pense que l'utilisateur a besoin de choisir entre l'effacement de type et la monomorphisation.
C'est pourquoi Rust fournit des abstractions à coût nul. Allez devrait aussi.

Le lun. 9 avril 2018, 08:32 Antonenko Artem [email protected]
a écrit:

@mandolyte https://github.com/mandolyte vous pouvez ajouter un autre niveau de
l'indirection en enveloppant des types spécialisés dans un conteneur général. Cette
façon dont votre implémentation peut rester la même. Le compilateur fera alors tout
la magie. Je pense que la proposition de paramètres de type de Ian fonctionne de cette façon.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment-379735199 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AGGWB1v9h5kWmuHCBuoewTTSX751OHgrks5tm1TsgaJpZM4IG-xv
.

Il me semble qu'il y a une confusion compréhensible dans cette discussion sur le compromis entre modularité et performance. La technique C++ de re-vérification de type et d'instanciation du code générique à chaque type pour lequel il est utilisé est mauvaise pour la modularité, mauvaise pour les distributions binaires et, à cause du gonflement du code, mauvaise pour les performances. La bonne partie de cette approche est qu'elle spécialise automatiquement le code généré aux types utilisés, ce qui est particulièrement utile lorsque les types utilisés sont des types primitifs comme int . Java traduit de manière homogène le code générique, mais paie un prix en termes de performances, en particulier lorsque le code utilise le type T[] .

Heureusement, il existe plusieurs façons de résoudre ce problème sans la non-modularité de C++ et sans génération de code d'exécution complète :

1. Générez des instanciations spécialisées pour les types primitifs. Cela peut être fait automatiquement ou par une directive du programmeur. Un certain dispatching est nécessaire pour accéder à l'instanciation correcte, mais peut être intégré au dispatching déjà nécessaire par une traduction homogène. Cela fonctionnerait de la même manière que C #, mais ne nécessite pas de génération de code d'exécution complète ; une petite prise en charge supplémentaire peut être souhaitable dans le runtime pour configurer les tables de répartition lors des chargements de code.
2. Utilisez une implémentation générique unique dans laquelle un tableau de T est en fait représenté comme un tableau d'un type primitif lorsque T est instancié comme un type primitif. Cette approche, que nous avons utilisée dans PolyJ, Genus et Familia, améliore considérablement les performances par rapport à l'approche Java, bien qu'elle ne soit pas aussi rapide qu'une implémentation entièrement spécialisée.

@dc0d

Le polymorphisme n'est pas atteint en ayant des types compatibles, lors de la reliaison des alias de type. La seule contrainte réelle est le corps du package générique. Ils doivent être compatibles mécaniquement.

Les alias de type ne sont pas le bon moyen, car il devrait s'agir d'une référence constante.
Il est préférable d'écrire 'T Type' directement et vous voyez alors que vous utilisez effectivement des génériques.

Pourquoi voulez-vous utiliser une variable de type globale 'T' pour l'ensemble du package/module, les variables de type locales dans <> ou [] sont plus modulaires.

@creker

En particulier, C # comme le plus familier pour moi. Mais il utilise la génération de code d'exécution que l'équipe Go exclut complètement.

Pour les types référence, mais pas pour les types valeur.

@DemiMarie

Je pense que l'utilisateur a besoin de choisir entre l'effacement de type et la monomorphisation.
C'est pourquoi Rust fournit des abstractions à coût nul. Allez devrait aussi.

"Type Erasure" est ambigu, je suppose que vous voulez dire Type Parameter Erasure, la chose que Java fournit qui n'est pas non plus tout à fait vraie.
Java a une monomorphisation, mais il monomorphise (semi) constamment jusqu'à la limite supérieure de la contrainte générique qui est principalement Object.
Pour fournir des méthodes et des champs d'autres types, la limite supérieure est convertie en interne dans votre type approprié, ce qui est assez moche.
Si le projet Valhalla est accepté, les choses changeront pour les types valeur mais malheureusement pas pour les types référence.

Go n'est pas obligé de suivre Java Way car :

"La compatibilité binaire des packages compilés n'est pas garantie entre les versions"

alors que ce n'est pas possible en Java.

Il me semble qu'il y a une confusion compréhensible dans cette discussion sur le compromis entre modularité et performance. La technique C++ de re-vérification de type et d'instanciation du code générique à chaque type pour lequel il est utilisé est mauvaise pour la modularité, mauvaise pour les distributions binaires et, à cause du gonflement du code, mauvaise pour les performances.

De quel type de performance parlez-vous ici ?

Si par "gonflement du code" et "performances", vous entendez "taille binaire" et "pression du cache d'instructions", alors le problème est assez simple à résoudre : tant que vous ne conservez pas trop d'informations de débogage pour chaque spécialisation, vous pouvez regrouper les fonctions avec les mêmes corps dans la même fonction au moment de la liaison (ce que l'on appelle le "modèle de Borland" ). Cela gère trivialement les spécialisations pour les types primitifs et les types sans appels à des méthodes non triviales.

Si par "gonflement du code" et "performances", vous entendez "taille d'entrée de l'éditeur de liens" et "temps de liaison", alors le problème est également assez simple, si vous pouvez faire certaines hypothèses (raisonnables) sur votre système de construction. Au lieu d'émettre chaque spécialisation dans chaque unité de compilation, vous pouvez à la place émettre une liste des spécialisations nécessaires et faire en sorte que le système de construction instancie chaque spécialisation unique exactement une fois avant la liaison (le "modèle Cfront"). IIRC, c'est l'un des problèmes que les modules C++ tentent de résoudre.

Donc, à moins que vous ne parliez d'un troisième type de "gonflement du code" et de "performances" que j'ai manqué, il semble que vous parliez d'un problème avec l'implémentation, pas la spécification : _tant que l'implémentation ne conserve pas trop le débogage informations,_ les problèmes de performances sont assez simples à résoudre.

Le plus gros problème pour Go est que, si nous ne faisons pas attention, il devient possible d'utiliser des assertions de type ou une réflexion pour produire une nouvelle instance d'un type paramétré au moment de l'exécution, ce qui ne nécessite aucune intelligence d'implémentation - à moins d'un ensemble coûteux. ‐analyse de programme — peut réparer.

C'est en effet un échec de la modularité, mais cela n'a ~rien à voir avec le gonflement du code : au lieu de cela, cela vient du fait que les types de fonctions Go (et de méthodes) ne capturent pas un ensemble suffisamment complet de contraintes sur leurs arguments.

@sighoya

Pour les types référence, mais pas pour les types valeur.

D'après ce que j'ai lu, C # JIT effectue une spécialisation au moment de l'exécution pour chaque type de valeur et une fois pour tous les types de référence. Il n'y a pas de spécialisation au moment de la compilation (IL-time). C'est pourquoi l'approche C # est complètement ignorée - l'équipe Go ne veut pas dépendre de la génération de code d'exécution car elle limite les plates-formes sur lesquelles Go peut s'exécuter. En particulier, sur iOS, vous n'êtes pas autorisé à générer du code lors de l'exécution. Cela fonctionne et j'en ai fait une partie, mais Apple ne l'autorise pas dans l'AppStore.

Comment avez-vous fait?

Le lun. 9 avril 2018, 15:41 Antonenko Artem [email protected]
a écrit:

@sighoya https://github.com/sighoya

Pour les types référence, mais pas pour les types valeur.

D'après ce que j'ai lu, C # JIT effectue une spécialisation au moment de l'exécution pour chaque valeur
type et une fois pour tous les types de référence. Il n'y a pas de temps de compilation
spécialisation. C'est pourquoi l'approche C # est complètement ignorée - Go team
ne veut pas dépendre de la génération de code d'exécution car cela limite les plates-formes Go
peut fonctionner. En particulier, sur iOS, vous n'êtes pas autorisé à générer du code
à l'exécution. Cela fonctionne et j'en ai fait une partie mais Apple ne le permet pas
dans l'AppStore.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment-379870005 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AGGWB-tslGeUSGXl2ZlEDLf0dCATUaYvks5tm7lvgaJpZM4IG-xv
.

@DemiMarie a lancé mon ancien code de recherche juste pour être sûr (que la recherche a été abandonnée pour d'autres raisons). Encore une fois, le débogueur m'a induit en erreur. J'alloue une page, j'y écris des instructions, je la protège avec PROT_EXEC et j'y saute. Sous débogueur, cela fonctionne. Sans le débogueur, l'application est SIGKILLed avec le message CODESIGN dans le journal des plantages, comme prévu. Donc, cela ne fonctionne pas même sans AppStore. Argument encore plus fort contre la génération de code d'exécution si iOS est important pour Go.

Tout d'abord, il serait utile de réfléchir une fois de plus aux 5 règles de programmation de Rob Pike .

Deuxièmement (à mon humble avis):

À propos de la lenteur de la compilation et de la taille binaire, combien de types génériques sont utilisés dans les types courants d'applications développées à l'aide de Go (_n est généralement petit_ d'après la règle 3) ? À moins que le problème n'ait besoin d'un niveau élevé de cardinalité dans des concepts concrets (nombre élevé de types), cette surcharge peut être négligée. Même alors, je dirais que quelque chose ne va pas avec cette approche. Lors de la mise en œuvre d'un système de commerce électronique, personne ne définit un type distinct pour chaque type de produit et ses variations et peut-être les personnalisations possibles.

La verbosité est une bonne forme de simplicité et de familiarité (par exemple dans la syntaxe) qui rend les choses plus évidentes et plus propres. Bien que je doute que le gonflement du code soit plus élevé en utilisant Type Alias ​​Rebinding, j'aime la syntaxe Go-ish familière et la verbosité évidente qui l'accompagne. L'un des objectifs de Go est d'être facile à lire (alors que je trouve personnellement qu'il est relativement facile et agréable d'écrire aussi).

Je ne comprends pas comment cela peut nuire aux performances car au moment de l'exécution, seuls des types bornés concrets sont utilisés qui ont été générés au moment de la compilation. Il n'y a pas de surcharge d'exécution.

Le seul problème avec Type Alias ​​Rebinding que je vois, pourrait être la distribution binaire.

@ dc0d les dommages aux performances signifient généralement le remplissage du cache d'instructions en raison de différentes implémentations de modèles de classe. Comment cela se rapporte-t-il exactement à la performance réelle est une question ouverte, je ne connais aucun point de repère, mais théoriquement, c'est un problème.

Quant à la taille binaire. C'est un autre problème théorique que les gens soulèvent généralement (comme je l'ai fait plus tôt), mais comment le vrai code en souffrira est, encore une fois, une question ouverte. Par exemple, la spécialisation pour tous les types de pointeurs et d'interfaces pourrait être la même, je pense. Mais la spécialisation pour tous les types de valeur serait unique. Et cela inclut également les structures. L'utilisation de conteneurs génériques pour les stocker est courante et entraînerait un gonflement important du code, car les implémentations de conteneurs génériques ne sont pas petites.

Le seul problème avec Type Alias ​​Rebinding que je vois, pourrait être la distribution binaire.

Ici, je ne suis toujours pas sûr. La proposition de génériques doit-elle prendre en charge les packages uniquement binaires ou nous pourrions simplement mentionner que les packages uniquement binaires ne prennent pas en charge les génériques. Ce serait beaucoup plus facile, c'est certain.

Comme mentionné précédemment, si l'on n'a pas besoin de supporter le débogage, on
peut combiner des instanciations de modèles identiques.

Le mar. 10 avril 2018, 05:46 Kaveh Shahbazian [email protected]
a écrit:

Tout d'abord, il serait utile de réfléchir aux 5 règles de programmation de Rob Pike
https://users.ece.utexas.edu/%7Eadnan/pike.html une fois de plus.

Deuxièmement (à mon humble avis):

À propos de la compilation lente et de la taille binaire, combien de types génériques sont utilisés dans
types courants d'applications développées à l'aide de Go ( n estgénéralement petit de la règle 3) ? À moins que le problème nécessite un niveau élevé de
cardinalité dans les concepts concrets (nombre élevé de types) que les frais généraux peuvent
être négligé. Même alors, je dirais que quelque chose ne va pas avec ça
approcher. Lors de la mise en œuvre d'un système de commerce électronique, personne ne définit un
type pour chaque type de produit et ses variations et peut-être le possible
personnalisations.

La verbosité est une bonne forme de simplicité et de familiarité (par exemple dans
syntaxe) qui rend les choses plus évidentes et plus propres. Alors que j'en doute
le gonflement du code serait plus élevé en utilisant Type Alias ​​Rebinding, j'aime bien le
syntaxe Go-ish familière et la verbosité évidente qui l'accompagne. Un des
les objectifs de Go sont faciles à lire (alors que je le trouve personnellement
relativement facile et agréable à écrire aussi).

Je ne comprends pas comment cela peut nuire aux performances car lors de l'exécution, seul
des types bornés concrets sont utilisés qui ont été générés à
au moment de la compilation. Il n'y a pas de surcharge d'exécution.

Le seul problème avec Type Alias ​​Rebinding que je vois, pourrait être le binaire
Distribution.

—
Vous recevez ceci parce que vous avez été mentionné.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment-380040032 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AGGWB6aDfoHz2wbsmu8mCGEt652G_VE9ks5tnH9xgaJpZM4IG-xv
.

Les instanciations n'ont même pas besoin d'être "identiques" dans le sens "d'utiliser les mêmes arguments", ou même "d'utiliser des arguments avec le même type sous-jacent". Ils doivent juste être suffisamment proches pour aboutir au même code généré. (Pour Go, cela implique également "les mêmes masques de pointeur".)

@creker

D'après ce que j'ai lu, C # JIT effectue une spécialisation au moment de l'exécution pour chaque type de valeur et une fois pour tous les types de référence. Il n'y a pas de spécialisation au moment de la compilation (IL-time).

Eh bien, c'est parfois un peu compliqué car leur byte code est interprété juste à temps avant l'exécution du code, donc la génération de code se fait avant l'exécution du programme mais après la compilation, donc vous avez raison dans le sens de la vm qui s'exécute pendant que le code est généré.

Je pense que le système générique de c # serait parfait si nous générions plutôt du code au moment de la compilation.
La génération de code d'exécution au sens de c# n'est pas possible avec go, car go n'est pas une machine virtuelle.

@dc0d

Le seul problème avec Type Alias ​​Rebinding que je vois, pourrait être la distribution binaire.

Pouvez-vous élaborer un peu.

@sighoya Mon erreur ; Je ne parlais pas de distribution binaire mais de packages binaires - dont personnellement je n'ai aucune idée de l'importance.

@creker Joli résumé ! (MO) À moins qu'une raison valable ne soit trouvée, toute forme de surcharge des constructions du langage Go doit être évitée. L'une des raisons d'utiliser Type Alias ​​Rebinding est d'éviter de surcharger les types composites intégrés tels que les tranches ou les cartes.

La verbosité est une bonne forme de simplicité et de familiarité (par exemple dans la syntaxe) qui rend les choses plus évidentes et plus propres. Bien que je doute que le gonflement du code soit plus élevé en utilisant Type Alias ​​Rebinding, j'aime la syntaxe Go-ish familière et la verbosité évidente qui l'accompagne. L'un des objectifs de Go est d'être facile à lire (alors que je trouve personnellement qu'il est relativement facile et agréable d'écrire aussi).

Je ne suis pas d'accord avec cette notion. Votre proposition obligera les utilisateurs à faire la chose la plus difficile connue de tout programmeur - nommer les choses. Nous nous retrouverons donc avec un code criblé de notation hongroise, qui non seulement a l'air mauvais, mais qui est inutilement verbeux et provoque des bégaiements. De plus, d'autres propositions apportent également une syntaxe go-ish, et en même temps n'ont pas ces problèmes.

Il existe trois catégories de noms que nous devons inventer au quotidien :

• Pour les entités de domaine/la logique
• Types de données/logique du flux de travail du programme
• Services/Types de données d'interfaçage/Logique

Combien de fois un programmeur avait-il réussi à éviter de nommer quoi que ce soit dans son code, jamais ?

Difficile ou pas, cela doit être fait quotidiennement. Et la plupart de ses obstacles proviennent de l'incompétence à structurer une base de code - et non des difficultés du processus de nommage lui-même. Cette citation - du moins dans sa forme actuelle - a rendu un très mauvais service au monde de la programmation jusqu'à présent. Il essaie simplement de souligner l'importance de nommer. Parce que nous communiquons via des noms dans notre code.

Et les noms deviennent d'autant plus puissants lorsqu'ils accompagnent une pratique de structuration de code ; à la fois en termes de disposition du code (un fichier, une structure de répertoires, des packages/modules) et des pratiques (modèles de conception, abstractions de service - telles que REST, gestion des ressources - programmation simultanée, accès au disque dur, débit/latence).

En ce qui concerne la syntaxe et la verbosité, je privilégie la verbosité à une concision intelligente (au moins dans le contexte de Go) - encore une fois, Go est censé être facile à lire, pas nécessairement facile à écrire (ce qui étrangement, je le trouve bien aussi) .

@jba voir https://github.com/golang/go/issues/8303 et https://github.com/golang/go/issues/8082

J'ai lu beaucoup de rapports d'expérience et de propositions sur pourquoi et comment implémenter des génériques dans Go.

Cela vous dérange-t-il si j'essaie de les implémenter dans ma gomacro d' interpréteur Go ?

J'ai une certaine expérience sur le sujet, ayant ajouté des génériques à deux langues dans le passé

1. un langage maintenant abandonné que j'ai créé quand j'étais naïf :) Il s'est transpilé en code source C
2. Common Lisp avec ma bibliothèque cl-parametric-types - il prend également en charge les spécialisations partielles et complètes des types et fonctions génériques

@cosmos72 ça ferait un beau reportage d'expérience de voir un prototype d'une technique qui a préservé la sécurité de type.

Je viens de commencer à travailler dessus. Vous pouvez suivre l'avancement sur https://github.com/cosmos72/gomacro/tree/generics-v1

Pour le moment, je commence par un mélange (légèrement modifié) des troisième et quatrième propositions d'Ian répertoriées sur https://github.com/golang/proposal/blob/master/design/15292-generics.md#Proposal

@cosmos72 Il y a un résumé des propositions sur le lien ci-dessous. Votre mélange en fait-il partie ?
https://docs.google.com/document/d/1vrAy9gMpMoS3uaVphB32uVXX4pi-HnNjkMEgyAHX4N4

J'ai lu ce document, il résume de nombreuses approches différentes des génériques par divers langages de programmation.

Pour le moment, je me dirige vers la technique de "spécialisation de type" utilisée par C++, Rust et d'autres, éventuellement avec un peu de "portées de modèle paramétrées" car Go la syntaxe la plus générale pour les nouveaux types est type ( Foo ...; Bar ...) et j'étends à template[T1,T2...] type ( Foo ...; Bar ...) .
Aussi, je garde la porte ouverte à la "spécialisation contrainte".

Je voudrais également implémenter la "spécialisation de la fonction polymorphe", c'est-à-dire faire en sorte que la spécialisation soit automatiquement déduite par la langue sur le site d'appel si elle n'est pas spécifiée par le programmeur, mais je suppose que cela peut être quelque peu complexe à implémenter. Nous verrons.

Le mélange auquel je faisais référence est entre https://github.com/golang/proposal/blob/master/design/15292/2013-10-gen.md et https://github.com/golang/proposal/blob/ master/design/15292/2013-12-type-params.md

Mise à jour : pour éviter de spammer ce problème officiel de Go au-delà de l'annonce initiale, il est probablement préférable de poursuivre la discussion spécifique à gomacro sur le problème gomacro 24 : ajouter des génériques

Mise à jour 2 : premières fonctions de modèle compilées et exécutées avec succès. Voir https://github.com/cosmos72/gomacro/tree/generics-v1

Pour mémoire, il est possible de reformuler mon avis (sur les génériques et Type Alias ​​Rebinding) :

Les génériques doivent être ajoutés en tant que fonctionnalité du compilateur (génération de code, modèles, etc.), et non en tant que fonctionnalité du langage (ingérence avec le système de type de Go à tous les niveaux).

@dc0d
Mais les modèles C++ ne sont-ils pas un compilateur et une fonctionnalité de langage ?

@sighoya La dernière fois que j'ai écrit C++ professionnellement, c'était vers 2001. Je me trompe donc peut-être. Mais en supposant que les implications de la dénomination sont exactes - la partie "modèle" - oui (ou plutôt non); il peut s'agir d'une fonctionnalité de compilateur (et non d'une fonctionnalité de langage), accompagnée de certaines constructions de langage, qui ne surchargent probablement pas les constructions de langage impliquées dans le système de type.

Je soutiens @dc0d. Si vous le considérez, cette fonctionnalité ne serait rien de plus qu'un générateur de code intégré.

Oui : la taille binaire peut augmenter et VA augmenter, mais pour le moment, nous utilisons des générateurs de code, qui sont à peu près les mêmes mais en tant que fonctionnalité externe. Si je dois créer mon modèle en tant que :

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

... J'aimerais sérieusement que, plutôt que de copier-coller ou d'utiliser un outil externe, cette fonctionnalité fasse partie du compilateur lui-même.

Veuillez noter:

• Oui, le code de fin serait dupliqué. Exactement comme si nous utilisions un générateur. Et le binaire serait plus grand.
• Oui, l'idée n'est pas originale, mais empruntée au C++.
• Oui, fonctions de MyTypen'impliquant rien avec le type T (directement ou indirectement) serait également répété. Cela pourrait être optimisé (par exemple, les méthodes qui font référence à quelque chose de type T -autre que le pointeur vers l'objet de réception de message- seront générées pour chaque T ; les méthodes qui contiennent des invocations à des méthodes qui être généré pour chaque T , sera également généré pour chaque T , de manière récursive - tandis que les méthodes où leur seule référence à T est *T dans le récepteur, et d'autres méthodes n'appelant que ces méthodes sûres et satisfaisant aux mêmes critères, ne pourront être faites qu'une seule fois). Quoi qu'il en soit, IMO ce point est important et moins pertinent : je serais plutôt content même si cette optimisation n'existe pas.
• Les arguments de type doivent être explicites à mon avis. Surtout quand un objet satisfait des interfaces potentiellement infinies. Encore une fois : un générateur de code.

Jusqu'à présent dans mon commentaire, ma proposition est de l'implémenter tel quel : en tant que générateur de code pris en charge par le compilateur , au lieu d'un outil externe.

Il serait dommage que Go suive la route C++. Beaucoup de gens considèrent l'approche C++ comme un gâchis qui a retourné les programmeurs contre toute l'idée des génériques : difficulté de débogage, manque de modularité, gonflement du code. Toutes les solutions de "générateur de code" ne sont en réalité que des substitutions de macros - si c'est ainsi que vous voulez écrire du code, pourquoi avons-nous même besoin du support du compilateur ?

@andrewcmyers J'ai eu cette proposition Type Alias ​​Rebinding dans laquelle nous écrivons uniquement des packages normaux et au lieu d'utiliser interface{} explicitement, nous l'utilisons simplement comme type T = interface{} comme paramètre générique au niveau du package. Et c'est tout.

• Nous le déboguons comme un paquet normal - c'est du code réel, pas une créature à demi-vie intermédiaire.
• Il n'est pas nécessaire de se mêler du système de type Go à tous les niveaux - pensez uniquement à l'assignabilité.
• C'est explicite. Pas de mojo caché. Bien sûr, on pourrait trouver que le fait de ne pas pouvoir enchaîner les appels génériques de manière transparente est un inconvénient. Je le vois comme un tirage au sort ! Changer de type dans deux appels consécutifs, dans une seule déclaration n'est pas Goish (IMO).
• Et surtout, il est rétrocompatible avec la série Go 1.x (x >= 8).

Si l'idée n'est pas nouvelle, la manière dont Go permet de la mettre en œuvre est pragmatique et claire.

Autre bonus : il n'y a pas de surcharge d'opérateurs en Go. Mais en définissant la valeur par défaut de l'alias de type comme (par exemple) type T = int , ce ne sont pas les seuls types valides qui peuvent être utilisés pour personnaliser ce package générique, ce sont les types numériques qui ont une implémentation interne pour + Opérateur

De plus, le paramètre de type d'alias peut être forcé à remplir plus d'une interface simplement en ajoutant des types et des instructions de validateur.

Maintenant, ce serait super moche d'utiliser n'importe quelle notation explicite pour un type générique qui a un paramètre qui implémente les interfaces Error et Stringer et est également un type numérique qui prend en charge l'opérateur + !

en ce moment, nous utilisons des générateurs de code, qui sont à peu près les mêmes mais en tant que fonctionnalité externe.

La différence étant que la manière largement acceptée de générer du code (via go generate ) se produit au moment de la validation/du développement, et non au moment de la compilation. Le faire au moment de la compilation implique que vous devez autoriser l'exécution de code arbitraire dans le compilateur, les bibliothèques peuvent exploser les temps de compilation par ordre de grandeur et/ou vous aurez des dépendances de construction distinctes (c'est-à-dire que le code ne peut plus être construit uniquement avec le Go outil). J'aime Go pour pousser l'invocation de la méta-programmation au développeur en amont.

Autrement dit, comme toutes les approches pour résoudre ces problèmes, cette approche a également des inconvénients et implique des compromis. Personnellement, je dirais que les génériques réels avec prise en charge dans le système de type sont non seulement meilleurs (c'est-à-dire qu'ils ont un ensemble de fonctionnalités plus puissant), mais peuvent également conserver l'avantage d'une compilation prévisible et sûre.

Je vais lire tout ce qui précède, je le promets, et pourtant j'ajouterai un peu aussi - GoLang SDK pour Apache Beam semble un exemple/une vitrine plutôt brillant des problèmes que le concepteur de bibliothèque doit endurer pour réussir quoi que ce soit de _correctement_ de haut niveau.

Il existe au moins deux implémentations expérimentales pour les génériques Go. Plus tôt cette semaine, j'ai passé du temps avec (1). J'ai été ravi de constater que l'impact du code sur la lisibilité était minime. Et j'ai trouvé que l'utilisation de fonctions anonymes pour fournir des tests d'égalité fonctionnait bien; donc je suis convaincu que la surcharge de l'opérateur n'est pas nécessaire. Le seul problème que j'ai trouvé était dans la gestion des erreurs. L'idiome commun de "return nil,err" ne fonctionnera pas si le type est, par exemple, un entier ou une chaîne. Il existe plusieurs façons de contourner ce problème, toutes avec un coût de complexité. Je suis peut-être un peu bizarre, mais j'aime la gestion des erreurs de Go. Cela m'amène donc à observer qu'une solution générique Go devrait avoir un mot-clé universel pour la valeur zéro d'un type. Le compilateur le remplacerait simplement par zéro pour les types numériques, une chaîne vide pour les types de chaîne et nil pour les structures.

Bien que cette implémentation n'impose pas une approche au niveau du package, il serait certainement naturel de le faire. Et, bien sûr, cette implémentation n'abordait pas tous les détails techniques sur l'emplacement du code instancié du compilateur (le cas échéant), le fonctionnement des débogueurs de code, etc.

C'était plutôt agréable d'utiliser le même code d'algorithme pour les entiers et quelque chose comme un point :

type Point struct {
    x,y int
}

Voir (2) pour mes tests et mes observations.

(1) https://github.com/albrow/fo ; l'autre est le https://github.com/cosmos72/gomacro#generics susmentionné
(2) https://github.com/mandolyte/fo-experiments

@mandolyte Vous pouvez utiliser *new(T) pour obtenir la valeur zéro de n'importe quel type.

Une construction de langage comme default(T) ou zero(T) (la première est celle
en C# IIRC) serait clair, mais OTOH plus long que *new(T) (bien que plus
performantes).

2018-07-06 9:15 GMT-05:00 Tom Thorogood [email protected] :

@mandolyte https://github.com/mandolyte Vous pouvez utiliser *new(T) pour obtenir le
valeur zéro de tout type.

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment-403046735 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AlhWhQ5cQwnc3x_XUldyJXCHYzmr6aN3ks5uD3ETgaJpZM4IG-xv
.

--
Ceci est un test pour les signatures de courrier à utiliser dans TripleMint

19642 est pour discuter d'une valeur zéro générique

@tmthrgd D'une manière ou d'une autre, j'ai raté cette petite friandise. Merci!

prélude

Les génériques consistent à spécialiser les constructions personnalisables. Trois catégories de spécialisation sont :

• Types spécialisés, Type<T> - un _tableau_ ;
• Calculs spécialisés, F<T>(T) ou F<T>(Type<T>) - un _tableau triable_ ;
• Notation spécialisée, _LINQ_ par exemple - instructions select ou for en Go ;

Bien sûr, il existe des langages de programmation qui présentent des constructions encore plus génériques. Mais les langages de programmation conventionnels comme _C++_, _C#_ ou _Java_ fournissent plus ou moins de constructions de langage limitées à cette liste.

les pensées

La première catégorie de types/constructions génériques doit être indépendante du type.

La deuxième catégorie de types/constructions génériques doit _agir_ sur une _propriété_ du paramètre de type. Par exemple, un _tableau triable_ doit pouvoir _comparer_ la _propriété comparable_ de ses éléments. En supposant T.(P) est une propriété de T et que A(T.(P)) est un calcul/action qui agit sur cette propriété, le (A, .(P)) peut être appliqué soit à chaque élément individuel ou être déclaré comme calcul spécialisé, passé au calcul personnalisable d'origine. Un exemple de ce dernier cas dans Go est l'interface sort.Interface qui a également la fonction distincte correspondante sort.Reverse .

La troisième catégorie de types/constructions génériques sont les notations de langage _spécialisées_ par type - ne semble pas être une chose Go _en général_.

des questions

à suivre ...

Tout commentaire plus descriptif qu'un emoji est le bienvenu !

@ dc0d Je recommanderais d'étudier les "éléments de programmation" de Sepanov avant d'essayer de définir les génériques. Le TL; DR est que nous écrivons du code concret pour commencer, disons un algorithme qui trie un tableau. Plus tard, nous ajoutons d'autres types de collection comme un Btree, etc. Nous remarquons que nous écrivons de nombreuses copies de l'algorithme de tri qui sont essentiellement les mêmes, nous définissons donc un concept, disons "triable". Maintenant, nous voulons catégoriser les algorithmes de tri, peut-être par modèle d'accès dont ils ont besoin, disons vers l'avant uniquement, un seul passage (un flux), vers l'avant uniquement plusieurs passages (une liste liée individuellement), bidirectionnel (une liste doublement liée), accès aléatoire (un déployer). Lorsque nous ajoutons un nouveau type de collection, nous n'avons qu'à indiquer à quelle catégorie de "coordonnées" il appartient pour avoir accès à tous les algorithmes de tri pertinents. Ces catégories d'algorithmes ressemblent beaucoup aux interfaces "Go". Je chercherais à étendre les interfaces dans Go pour prendre en charge plusieurs paramètres de type et les types abstraits/associés. Je ne pense pas que les fonctions aient besoin d'un paramétrage de type ad hoc.

@ dc0d Pour tenter de diviser les génériques en composants, je n'avais pas considéré 3, "notation spécialisée", comme sa propre partie distincte auparavant. Peut-être pourrait-il être caractérisé comme définissant les DSL en utilisant des contraintes de type.

Je pourrais dire que vos 1 et 2 sont respectivement des "structures de données" et des "algorithmes". Avec cette terminologie, il est un peu plus clair pourquoi il peut être difficile de les séparer proprement, car ils sont souvent très dépendants les uns des autres. Mais sort.Interface est un assez bon exemple de l'endroit où vous pouvez tracer une ligne entre le stockage et le comportement (avec un peu de sucre récent pour le rendre plus agréable), car il encode les exigences Indexable et Comparable dans le comportement minimum nécessaire pour implémenter l'algorithme de tri avec "swap" et "moins" (et len). Mais cela semble s'effondrer sur des structures de données plus compliquées comme les arbres ou les tas, qui nécessitent actuellement quelques contorsions pour être mappés en comportement pur en tant qu'interfaces Go.

Je pourrais imaginer un ajout relativement petit de génériques aux interfaces (ou autrement) qui pourrait permettre à la plupart des structures de données et des algorithmes des manuels d'être implémentés relativement proprement sans contorsions (comme sort.Interface l'est aujourd'hui), mais pas assez puissant pour concevoir des DSL. La question de savoir si nous voulons nous limiter à une implémentation de génériques aussi restreinte alors que nous nous donnons la peine d'ajouter des génériques est une autre question.

Les structures de coordonnées @infogulch pour les arbres binaires sont des "coordonnées bifurquantes", et des équivalents existent pour d'autres arbres. Cependant, vous pouvez également projeter la commande d'un arbre à travers l'une des trois commandes, pré-commande, en commande et post-commande. Après avoir choisi l'un d'entre eux, l'arbre peut être adressé comme une coordonnée bidirectionnelle, et la famille d'algorithmes de tri définis sur des coordonnées bidirectionnelles serait d'une efficacité optimale.

Le fait est que vous catégorisez les algorithmes de tri en fonction de leurs modèles d'accès. Il n'y a qu'un nombre fini d'algorithmes de tri optimaux pour chaque modèle d'accès. Vous ne vous souciez pas des structures de données à ce stade. Parler de structures plus complexes passe à côté de l'essentiel, nous voulons catégoriser la famille des algorithmes de tri et non les structures de données. Quelles que soient les données dont vous disposez, vous devrez utiliser l'un des algorithmes existants pour les trier. La question est donc de savoir laquelle des catégorisations de modèles d'accès aux données disponibles des algorithmes de tri est optimale pour les structures de données dont vous disposez.

(A MON HUMBLE AVIS)

@infogulch

Peut-être pourrait-il être caractérisé comme définissant les DSL en utilisant des contraintes de type

Vous avez raison. Mais comme ils font partie de l'ensemble des constructions de langage, l'OMI les appelant DSL serait un peu inexact.

1 et 2 ... sont souvent très dépendants

Encore vrai. Mais il existe de nombreux cas où il est nécessaire de transmettre un type de conteneur, alors que l'utilisation réelle n'est pas encore décidée - à ce stade d'un programme. C'est pourquoi 1 doit être étudié seul.

sort.Interface est un assez bon exemple où vous pouvez tracer une ligne entre _storage_ et _behavior_

Bien dit;

cela semble s'effondrer sur des structures de données plus compliquées

C'est une de mes questions : généraliser le paramètre de type et le décrire en termes de restrictions (comme List<T> where T:new, IDisposable ) ou fournir un _protocole_ généralisé applicable à tous les éléments (d'un ensemble ; d'un certain type) ?

@keean

la question devient laquelle des catégorisations de modèles d'accès aux données disponibles des algorithmes de tri est optimale pour les structures de données que vous avez

Vrai. L'accès par index est une _propriété_ d'une tranche (ou d'un tableau). Ainsi, la première exigence pour un conteneur triable (ou un conteneur _tree_ -able quel que soit l'algorithme _tree_) est de fournir un utilitaire _access & mutate (swap)_. La deuxième exigence est que les éléments doivent être comparables. C'est la partie déroutante (pour moi) de ce que vous appelez les algorithmes : les exigences doivent être remplies des deux côtés (sur le conteneur et sur le paramètre de type). C'est là que je ne peux pas imaginer une implémentation pragmatique des génériques en Go. Chaque côté du problème peut être parfaitement décrit en termes d'interfaces. Mais comment combiner ces deux dans une notation efficace ?

Les algorithmes @dc0d nécessitent des interfaces, les structures de données les fournissent. Cela suffit pour une généralité complète, à condition que les interfaces soient suffisamment puissantes. Les interfaces sont paramétrées par types, mais vous avez besoin de variables de type.

Prenant l'exemple 'sort', 'Ord' est une propriété du type stocké dans le conteneur, pas le conteneur lui-même. Le modèle d'accès est une propriété du conteneur. Les modèles d'accès simples sont des « itérateurs », mais ce nom vient du C++, Stepanov a préféré les « coordonnées » car il peut être appliqué à des conteneurs multidimensionnels plus complexes.

En essayant de définir le tri, nous voulons quelque chose comme ceci :

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

Remarque : je ne suggère pas cette notation, j'essaie simplement d'intégrer d'autres travaux connexes, la clause requirements est dans la syntaxe préférée de Stepanov, le type de fonction provient de Haskell, dont les classes de types représentent probablement une bonne implémentation de ces concepts.

@keean
Je vous ai peut-être mal compris, mais je ne pense pas que vous puissiez simplement restreindre les algorithmes aux interfaces uniquement, du moins dans la manière dont les interfaces sont définies actuellement.
Considérez sort.Slice par exemple, nous sommes intéressés par le tri des tranches, et je ne vois pas comment on construirait une interface qui représenterait toutes les tranches.

@urandom vous faites abstraction des algorithmes et non des collections. Vous demandez donc quels modèles d'accès aux données existent dans les algorithmes de "tri", puis classez-les. Ainsi, peu importe que le conteneur soit une "tranche", nous n'essayons pas de définir toutes les opérations que vous souhaitez effectuer sur une tranche, nous essayons de déterminer les exigences d'un algorithme et de l'utiliser pour définir une interface. Une tranche n'est pas spéciale, c'est juste un type T sur lequel nous pouvons définir un ensemble d'opérations.

Les interfaces sont donc liées à des bibliothèques d'algorithmes, et vous pouvez définir vos propres interfaces pour vos propres structures de données afin de pouvoir utiliser ces algorithmes. Les bibliothèques peuvent être livrées avec des interfaces prédéfinies pour les types intégrés.

@keean
Je pensais que c'était ce que tu voulais dire. Mais dans le contexte de Go, cela signifierait probablement qu'il faudrait une refonte importante de ce que les interfaces peuvent définir. J'imagine que diverses opérations intégrées, telles que des itérations ou des opérateurs, devraient être exposées via des méthodes pour que des choses comme sort.Slice ou math.Max soient rendues génériques sur les interfaces.

Vous devez donc prendre en charge l'interface suivante (pseudo-code):

type [T] OrderedIterator interface {
   Len() int
   ValueAt(i int) *T
}

...
package sort

func [T] Slice(s [T]OrderedIterator, func(i, j int) bool) {
   ...
}

et toutes les tranches auraient alors ces méthodes ?

@urandom Un itérateur n'est pas une abstraction d'une collection, mais une abstraction de la référence/pointeur dans une collection. Par exemple, l'itérateur avant pourrait avoir une seule méthode 'successeur' (parfois 'suivant'). Pouvoir accéder aux données à l'emplacement d'un itérateur n'est pas une propriété de l'itérateur (sinon vous vous retrouverez avec des versions d'itérateur en lecture/écriture/mutable). Il est préférable de définir les "références" séparément en tant qu'interfaces lisibles, inscriptibles et modifiables :

type T ForwardIterator interface {
   type DistanceType D
   successor(x T) T
}

type T Readable interface {
   type ValueType U 
   source(x T) U
}

Remarque : Le type 'T' n'est pas la tranche, mais le type de l'itérateur sur la tranche. Cela pourrait simplement être un simple pointeur, si nous adoptons le style C++ consistant à transmettre un itérateur de début et de fin à des fonctions telles que sort.

Pour un itérateur à accès aléatoire, nous nous retrouverions avec quelque chose comme :

type T RandomIterator interface {
   type DistanceType D
   setPosition(x DistanceType)
}

Ainsi, un itérateur/coordonnée est une abstraction de la référence à une collection, pas la collection elle-même. Le nom 'coordinate' exprime cela assez bien, si vous considérez l'itérateur comme la coordonnée et la collection comme la carte.

Ne vendons-nous pas Go short en ne tirant pas parti des fermetures de fonctions et des fonctions anonymes ? Avoir des fonctions/méthodes comme type de première classe dans Go peut aider. Par exemple, en utilisant la syntaxe de albrow/fo , un tri à bulles pourrait ressembler à ceci :

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

Veuillez ignorer toutes les erreurs... complètement non testées !

@mandolyte Je ne sais pas si cela m'a été adressé ? Je ne vois pas vraiment de différence entre ce que je suggérais et votre exemple, sauf que vous utilisez des interfaces multi-paramètres, et je donnais des exemples utilisant des types abstraits/associés. Pour être clair, je pense que vous avez besoin à la fois d'interfaces multi-paramètres et de types abstraits/associés pour une généralité totale, dont aucun n'est actuellement pris en charge par Go.

Je dirais que vos interfaces sont moins générales que celles que j'ai proposées, car elles lient l'ordre de tri, le modèle d'accès et l'accessibilité dans la même interface, ce qui entraînera bien sûr la prolifération d'interfaces, par exemple deux ordres (moins , supérieur), trois types d'accès (lecture seule, écriture seule, mutable) et cinq modèles d'accès (passage unique direct, passage multiple direct, bidirectionnel, indexé, aléatoire) conduiraient à 36 interfaces contre seulement 11 si les préoccupations sont séparées.

Vous pourriez définir les interfaces que je propose avec des interfaces multi-paramètres au lieu de types abstraits comme ceci :

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
}

Notez que le seul qui nécessite deux paramètres de type est l'interface Readable. Cependant, nous perdons cette capacité pour un objet itérateur de 'contenir' le type des objets itérés, ce qui est un gros problème car maintenant nous devons déplacer le type 'valeur' ​​dans le système de type, et nous devons le faire correctement . Cela conduit à une prolifération de paramètres de type qui n'est pas bonne, et cela augmente la possibilité d'erreurs de codage. Nous perdons également la possibilité de définir le 'DistanceType' sur l'itérateur, qui est le plus petit type de nombre nécessaire pour compter les éléments de la collection, ce qui est utile pour mapper sur int8, int16, int32, etc., pour donner le type dont vous avez besoin pour compter les éléments sans débordement.

Ceci est étroitement lié au concept de « dépendance fonctionnelle ». Si un type est fonctionnellement dépendant d'un autre type, il doit s'agir d'un type abstrait/associé. Ce n'est que si les deux types sont indépendants qu'ils doivent être des paramètres de type distincts.

Quelques problèmes:

1. Impossible d'utiliser la syntaxe f(x I) actuelle pour les interfaces multiparamètres. Je n'aime pas que cette syntaxe confond les interfaces (qui sont des contraintes sur les types) avec les types de toute façon.
2. Il faudrait un moyen de déclarer des types paramétrés.
3. Il devrait y avoir un moyen de déclarer les types associés pour les interfaces avec un ensemble donné de paramètres de type.

@keean Je ne suis pas sûr de comprendre comment ou pourquoi le nombre d'interfaces devient si élevé. Voici un exemple de travail complet : https://play.folang.org/p/BZa6BdsfBgZ (basé sur les tranches, pas sur un conteneur général, donc pas de méthode Next() nécessaire).

Il utilise une seule structure de type, aucune interface du tout. Je dois fournir toutes les fonctions et fermetures anonymes (c'est probablement là que se trouve le compromis ?). L'exemple utilise le même algorithme de tri à bulles pour trier à la fois une tranche d'entiers et une tranche de points "(x,y)", où la distance à l'origine est la base de la fonction Less().

En tout cas, j'espérais montrer comment avoir des fonctions dans le système de type peut aider.

@mandolyte Je pense que j'ai mal compris ce que vous proposiez. Je vois que ce dont vous parlez est "folang" qui a déjà quelques fonctionnalités de programmation fonctionnelles intéressantes ajoutées à Go. Ce que vous avez implémenté consiste essentiellement à créer manuellement une classe de types multiparamètres. Vous passez ce qu'on appelle un dictionnaire de fonctions à la fonction de tri. Cela fait explicitement ce qu'une interface ferait implicitement. Ce type de fonctionnalités est probablement nécessaire avant les interfaces multi-paramètres et les types associés, mais vous rencontrez éventuellement des problèmes pour transmettre tous ces dictionnaires. Je pense que les interfaces fournissent un code plus propre et plus lisible.

Trier une tranche est un problème résolu. Voici le code d'un slice quicksort.go implémenté à l'aide du langage go-li (golang amélioré) .

func main(){
    var data = []int{5,3,1,8,9}

    Sort(data, func(a *int, b *int) int {
        return *a - *b
    })

    fmt.Println(data)
}

Vous pouvez expérimenter cela sur le terrain de jeu

Exemple complet que vous pouvez coller dans le playground , car l'importation du package quicksort ne fonctionne pas sur le playground.

@go-li Je suis sûr que vous pouvez trier une tranche, ce serait un peu pauvre si vous ne le pouviez pas. Le fait est que, de manière générique, vous aimeriez pouvoir trier n'importe quel conteneur linéaire avec le même code, de sorte que vous n'ayez à écrire un algorithme de tri qu'une seule fois, quel que soit le conteneur (structure de données) que vous triez et quel que soit le le contenu est.

Lorsque vous pouvez le faire, la bibliothèque standard peut fournir des fonctions de tri universelles, et personne n'a plus jamais besoin d'en écrire une. Il y a deux avantages à cela, moins d'erreurs car il est plus difficile que vous ne le pensez d'écrire un algorithme de tri correct, Stepanov utilise l'exemple que la plupart des programmeurs ne peuvent pas définir correctement la paire 'min' et 'max', alors quel espoir avons-nous d'être correct pour les algorithmes plus complexes. L'autre avantage est que lorsqu'il n'y a qu'une seule définition de chaque algorithme de tri, toute amélioration de la clarté ou des performances qui peut être apportée profite à tous les programmes qui l'utilisent. Les gens peuvent passer leur temps à essayer d'améliorer l'algorithme commun au lieu d'avoir à écrire le leur pour chaque type de données différent.

@keean
Une autre question liée à notre discussion précédente. Je n'arrive pas à comprendre comment on pourrait définir une fonction de mappage qui change les éléments d'un itérable, renvoyant un nouveau type itérable concret dont les éléments pourraient être d'un type différent de celui d'origine.

Et j'imagine qu'un utilisateur d'une telle fonction voudrait qu'un type concret soit renvoyé, pas une autre interface.

@urandom En supposant que nous ne voulons pas le faire "sur place", ce qui serait dangereux, ce que vous voulez, c'est une fonction de carte qui a un "itérateur de lecture" d'un type et un "itérateur d'écriture" d'un autre type, qui peut être défini quelque chose comme :

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)

Pour plus de clarté, "ValueType" est un type associé des interfaces "Readable" et "Writable", "Domain" et "Codomain" sont des types associés de l'interface "UnaryFunction". Cela aide évidemment beaucoup si le compilateur peut dériver automatiquement les interfaces pour les types de données comme "UnaryFunction". Bien que cela ressemble à de la réflexion, ce n'est pas le cas, et tout se passe au moment de la compilation en utilisant des types statiques.

@keean Comment modéliser ces contraintes Readable et Writable dans le contexte des interfaces Go actuelles ?

Je veux dire, quand nous avons un type A et que nous voulons convertir en type B , la signature de cette UnaryFunction serait func (input A) B (n'est-ce pas ?), mais comment cela peut-il être modélisé en utilisant uniquement des interfaces et comment ce générique map (ou filter , reduce , etc.) serait modélisé pour conserver le pipeline de types ?

@ geovanisouza92 Je pense que "Type Families" fonctionnerait bien car elles peuvent être implémentées comme un mécanisme orthogonal dans le système de type, puis intégrées dans la syntaxe des interfaces comme cela se fait dans Haskell.

Une famille de types est comme une fonction restreinte sur les types (un mappage). Comme les implémentations d'interface sont sélectionnées par type, nous pouvons fournir un mappage de type pour chaque implémentation.

Donc si on définit :

ValueType MyIntArrayIterator -> Int

Les fonctions sont un peu plus compliquées mais une fonction a un type, par exemple :

fn(x : Int) Float

On écrirait ce type :

Int -> Float

Il est important de réaliser que -> n'est qu'un constructeur de type infixe, comme '[]' pour un Array est un constructeur de type, nous pourrions tout aussi bien écrire ceci ;

Fn Int Float
Or
Fn<Int, Float>

Selon notre préférence pour la syntaxe de type. Maintenant, nous pouvons voir clairement comment nous pouvons définir :

Domain  Fn<Int, Float> -> Int
Codomain Fn<Int, Float> -> Float

Bien que nous puissions fournir toutes ces définitions à la main, elles peuvent facilement être dérivées par le compilateur.

Compte tenu de ces familles de types, nous pouvons voir que la définition de map que j'ai donnée ci-dessus ne nécessite que les types IO et U pour instancier le générique, car tous les autres types en dépendent fonctionnellement. Nous pouvons voir que ces types sont directement fournis par les arguments.

Merci, @keean.

Cela fonctionnerait bien pour les fonctions intégrées/prédéfinies. Êtes-vous en train de dire que le même concept serait appliqué aux fonctions définies par l'utilisateur ou aux bibliothèques utilisateur ?

Ces "familles de types" seront transportées pour l'exécution, dans le cas d'un contexte d'erreur ?

Qu'en est-il des interfaces vides, des commutateurs de type et de la réflexion ?

EDIT : Je suis juste curieux, je ne me plains pas.

@ giovanisouza92 eh bien personne ne s'est engagé à avoir des génériques donc je m'attends à du scepticisme. Mon approche est que si vous allez faire des génériques, vous devez les faire correctement.

Dans mon exemple, 'map' est défini par l'utilisateur. Il n'y a rien de spécial à ce sujet, et dans la fonction, vous utilisez simplement les méthodes des interfaces dont vous avez besoin sur ces types exactement comme vous le faites actuellement dans Go. La seule différence est que nous pouvons exiger qu'un type satisfasse plusieurs interfaces, les interfaces peuvent avoir plusieurs paramètres de type (bien que l'exemple de carte ne l'utilise pas) et il existe également des types associés (et des contraintes sur les types comme l'égalité de type '==' mais c'est comme une égalité Prolog et unifie les types). C'est pourquoi il existe une syntaxe différente pour spécifier les interfaces requises par une fonction. Notez qu'il existe une autre différence importante :

f(x I, y I) requires ForwardIterator<I>

Vs

f(x ForwardIterator, y ForwardIterator)

Notez qu'il y a une différence dans ce dernier 'x' et 'y' peuvent être des types différents qui satisfont l'interface ForwardIterator, alors que dans l'ancienne syntaxe 'x' et 'y' doivent tous deux être du même type (ce qui satisfait l'itérateur avant). Ceci est important pour que les fonctions ne soient pas sous-contraintes et permettent aux types concrets d'être propagés beaucoup plus loin lors de la compilation.

Je ne pense pas que quoi que ce soit change concernant les changements de type et la réflexion, car nous ne faisons qu'étendre le concept d'interfaces. Comme go contient des informations sur le type d'exécution, vous ne rencontrez pas le même problème que Haskell et vous avez besoin de types existentiels.

En pensant à Go, au polymorphisme d'exécution et aux familles de types, nous voudrions probablement contraindre la famille de types elle-même à une interface pour éviter d'avoir à traiter chaque type associé comme une interface vide à l'exécution, ce qui serait lent.

Donc, à la lumière de ces réflexions, je modifierais ma proposition ci-dessus afin que lors de la déclaration d'une interface, vous déclariez une interface/un type pour chaque type associé que toutes les implémentations de cette interface devraient fournir un type associé qui satisfait cette interface. De cette façon, nous pouvons savoir qu'il est sûr d'appeler toutes les méthodes de cette interface sur les types associés au moment de l'exécution sans avoir à changer de type à partir d'une interface vide.

@keean
Dans l'intérêt de faire avancer le débat, permettez-moi de dissiper l'idée fausse qui me semble similaire au syndrome non inventé ici.

L'itérateur bidirectionnel (en syntaxe T func (*T) *[2]*T ) a le type func (*) *[2]* en syntaxe go-li. En mots, il prend un pointeur vers un certain type et renvoie un pointeur vers deux pointeurs vers l'élément suivant et précédent du même type. C'est le type fondamental fondamental concret utilisé par une liste doublement chaînée .

Maintenant vous pouvez écrire ce que vous appelez map, ce que j'appelle la fonction générique foreach. Ne vous méprenez pas, cela fonctionne non seulement sur une liste chaînée, mais sur tout ce qui expose un itérateur bidirectionnel !

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
}

Le Foreach peut être utilisé de deux manières, vous l'utilisez avec un lambda dans une itération de type boucle for sur des éléments de liste ou de collection.

const forward = 1
const backwards = 0
Foreach(iterator, collection, forward, func(element *element_type){
    // do something with every element
})

Ou vous pouvez l'utiliser pour mapper fonctionnellement une fonction à chaque élément de collection.

Foreach(iterator, collection, backwards, function_to_be_mapped_on_elements)

L'itérateur bidirectionnel peut bien sûr également être modélisé à l'aide d'interfaces dans go 1.
interface Iterator { Iter() [2]Iterator } Vous devez le modéliser à l'aide d'interfaces afin d'envelopper ("boîte") le type sous-jacent. L'utilisateur itérateur puis le type affirme le type connu une fois qu'il a localisé et souhaite visiter un élément de collection spécifique. Ceci est potentiellement dangereux au moment de la compilation.

Ce que vous décrivez ensuite, ce sont les différences entre l'approche héritée et l'approche basée sur les génériques.

func modern(x func  (*) *[2]*, y func  (*) *[2]*){}

cette approche compile time type vérifie que les deux collections ont le même type sous-jacent, c'est-à-dire si les itérateurs renvoient effectivement les mêmes types concrets

func modern_T_syntax<T>(x func  (*T) *[2]*T, y func  (*T) *[2]*T){}

Identique à ci-dessus mais en utilisant la syntaxe d'espace réservé de type T signifie familière

func legacy(x Iterator, y Iterator){}

Dans ce cas, l'utilisateur peut passer par exemple une liste liée entière comme x et une liste liée flottante comme y. Cela pourrait entraîner des erreurs d'exécution potentielles, des paniques ou d'autres décohérences internes, mais tout dépend de ce que l'héritage ferait avec les deux itérateurs.

Maintenant, l'idée fausse. Vous prétendez que faire des itérateurs et faire des tris génériques pour trier ces itérateurs serait la voie à suivre. Ce serait vraiment une mauvaise chose à faire, voici pourquoi

Itérateur et liste chaînée sont les deux faces d'une même médaille. Preuve : toute collection qui expose un itérateur s'annonce simplement comme une liste chaînée. Disons que vous devez trier cela. Qu'est-ce que?

Évidemment, vous supprimez la liste chaînée de votre base de code et la remplacez par un arbre binaire. Ou si vous voulez être fantaisiste, utilisez un arbre de recherche équilibré comme avl, rouge-noir, comme proposé il y a je ne sais combien d'années par Ian et tous. Cela n'a toujours pas été fait de manière générique dans golang. Maintenant, ce serait la voie à suivre.

Une autre solution consiste à effectuer rapidement une boucle temporelle O(N) sur l'itérateur, à collecter les pointeurs vers des éléments dans une tranche de pointeurs génériques, notée []*T et à trier ces pointeurs génériques à l'aide du mauvais tri par tranche

Merci de donner une chance aux idées des autres

@go-li Si nous voulons éviter le syndrome non inventé ici, nous devrions nous tourner vers Alex Stepanov pour une définition, car il a pratiquement inventé la programmation générique. Voici comment je le définirais, tiré de la page 111 "Elements of Programming" de Stepanov :

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

Cela dépend de la définition de ForwardIterator :

ForwardIterator<T> =
    Iterator<T>
/\ regular_unary_function(successor)

Nous avons donc essentiellement une interface qui déclare une fonction successor et une fonction predecessor , ainsi que certains axiomes auxquels elles doivent se conformer pour être valides.

En ce qui concerne legacy , ce n'est pas que l'héritage ira mal, il ne va évidemment pas mal dans Go actuellement, mais le compilateur manque des opportunités d'optimisation, et le système de type manque l'opportunité de propager davantage les types concrets. Cela limite également la capacité des programmeurs à spécifier précisément leur intention. Un exemple serait une fonction d'identité, ce que je veux dire pour renvoyer exactement le type qui lui est passé :

id(x T) T

Peut-être vaut-il également la peine de mentionner la différence entre un type paramétrique et un type universellement quantifié. Un type paramétrique serait id<T>(x T) T alors que celui universellement quantifié est id(x T) T (nous omettons normalement le quantificateur universel le plus externe dans ce cas forall T ). Avec les types paramétriques, le système de types doit avoir un type pour T fourni sur le site d'appel pour id , avec une quantification universelle qui n'est pas nécessaire tant que T est unifié avec un type concret avant la fin de la compilation. Une autre façon de comprendre cela est que la fonction paramétrique n'est pas un type mais un modèle pour un type, et ce n'est un type valide qu'après que T a été remplacé par un type concret. Avec la fonction universellement quantifiée, id a en fait un type forall T . T -> T qui peut être passé par le compilateur comme Int .

@go-li

Évidemment, vous supprimez la liste chaînée de votre base de code et la remplacez par un arbre binaire. Ou si vous voulez être fantaisiste, utilisez un arbre de recherche équilibré comme avl, rouge-noir, comme proposé il y a je ne sais combien d'années par Ian et tous. Cela n'a toujours pas été fait de manière générique dans golang. Maintenant, ce serait la voie à suivre.

Avoir des structures de données ordonnées ne signifie pas que vous n'avez jamais besoin de trier les données.

Si nous voulons éviter le syndrome du non-inventé ici, nous devrions nous tourner vers Alex Stepanov pour une définition, car il a pratiquement inventé la programmation générique.

Je contesterais toute affirmation selon laquelle la programmation générique aurait été inventée par C++. Lire Liskov et al. Article CACM de 1977 si vous voulez voir un premier modèle de programmation générique qui fonctionne réellement (type-safe, modulaire, pas de gonflement du code): https://dl.acm.org/citation.cfm?id=359789 (voir Section 4 )

Je pense que nous devrions arrêter cette discussion et attendre que l'équipe golang (russ) vienne avec quelques articles de blog, puis implémente une solution 👍 (voir vgo) Ils le feront 🎉

https://peter.bourgon.org/blog/2018/07/27/a-response-about-dep-and-vgo.html

J'espère que cette histoire servira d'avertissement aux autres : si vous êtes intéressé à apporter des contributions substantielles au projet Go, aucune diligence raisonnable indépendante ne peut compenser une conception qui ne provient pas de l'équipe principale.

Ce fil montre comment l'équipe principale n'est pas intéressée à participer activement à la recherche d'une solution avec la communauté.

Mais à la fin, s'ils peuvent à nouveau trouver une solution par eux-mêmes, ça me va, faites-le 👍

@andrewcmyers Eh bien peut-être que "inventé" était un peu exagéré, c'est probablement plus comme David Musser en 1971, qui a ensuite travaillé avec Stepanov sur certaines bibliothèques génériques pour Ada.

Elements of Programming n'est pas un livre sur C++, les exemples peuvent être en C++ mais c'est une chose très différente. Je pense que ce livre est une lecture essentielle pour quiconque souhaite implémenter des génériques dans n'importe quelle langue. Avant de renvoyer Stepanov, vous devriez vraiment lire le livre pour voir de quoi il s'agit réellement.

Ce problème dépasse déjà les limites de l'évolutivité de GitHub. Veuillez garder la discussion ici concentrée sur des questions concrètes pour les propositions Go.

Il serait dommage que Go suive la route C++.

@andrewcmyers Oui, je suis entièrement d'accord, veuillez ne pas utiliser C++ pour des suggestions de syntaxe ou comme référence pour faire les choses correctement. Au lieu de cela, veuillez jeter un œil à D pour vous inspirer .

@nomad-software

J'aime beaucoup D, mais a-t-il besoin des puissantes fonctionnalités de méta-programmation au moment de la compilation offertes par D ?

Je n'aime pas non plus la syntaxe des modèles en C++, issue de l'âge de pierre.

Mais qu'en est-il du ParametricType normalstandard trouvé en Java ou C #, si nécessaire, on peut également le surcharger avec ParametricType

Et plus loin, je n'aime pas la syntaxe d'appel de modèle en D avec son symbole bang, le symbole bang est plutôt utilisé de nos jours pour désigner un accès mutable ou immuable pour les paramètres d'une fonction.

@nomad-software Je ne suggérais pas que la syntaxe C++ ou le mécanisme de modèle est la bonne façon de faire des génériques. De plus, les "concepts" tels que définis par Stepanov traitent les types comme une algèbre, ce qui est tout à fait la bonne façon de faire des génériques. Regardez les classes de types Haskell pour voir à quoi cela pourrait ressembler. Les classes de type Haskell sont sémantiquement très proches des modèles et des concepts c++, si vous comprenez ce qui se passe.

Donc +1 pour ne pas suivre la syntaxe c++ et +1 pour ne pas implémenter un système de template non sécurisé :-)

@keean La raison de la syntaxe D est d'éviter complètement <,> et d'adhérer à une grammaire sans contexte. Cela fait partie de mon point d'utiliser D comme source d'inspiration. <,> est un très mauvais choix pour la syntaxe des paramètres génériques.

@nomad-software Comme je l'ai souligné ci-dessus (dans un commentaire désormais masqué), vous devez spécifier les paramètres de type pour les types paramétriques, mais pas pour les types universellement quantifiés (d'où la différence entre Rust et Haskell, la manière dont les types sont gérés est en fait différente dans le système de types). Concepts C++ également == classes de types Haskell == interfaces Go, au moins au niveau conceptuel.

La syntaxe D est-elle vraiment préférable :

auto add(T)(T lhs, T rhs) {
    return lhs + rhs;

Pourquoi est-ce mieux que le style C++/Java/Rust :

T add<T>(T lhs, T rhs) {
    return lhs + rhs;
}

Ou style Scala :

T add[T](T lhs, T rhs) {
    return lhs + rhs;
}

J'ai réfléchi à la syntaxe des paramètres de type. Je n'ai jamais été fan des "crochets angulaires" en C++ et Java car ils rendent l'analyse assez délicate et entravent ainsi le développement d'outils. Les crochets sont en fait un choix classique (de CLU, System F et d'autres langages anciens avec polymorphisme paramétrique).

Cependant, la syntaxe de Go est assez délicate, peut-être parce qu'elle est déjà si laconique. Les syntaxes possibles basées sur des crochets ou des parenthèses créent des ambiguïtés grammaticales encore pires que celles introduites par des crochets angulaires. Donc malgré mes prédispositions, les équerres semblent en fait être le meilleur choix pour Go. (Bien sûr, il existe aussi de vrais chevrons qui ne créeraient aucune ambiguïté — ⟨⟩ — mais ils nécessiteraient l'utilisation de caractères Unicode).

Bien sûr, la syntaxe précise utilisée pour les paramètres de type est moins importante que la bonne sémantique . Sur ce point, le langage C++ est un mauvais modèle. Les travaux de mon groupe de recherche sur les génériques dans Genus (PLDI 2015) et Familia (OOPSLA 2017) proposent une autre approche qui étend les classes de types et les unifie avec des interfaces.

@andrewcmyers Je pense que ces deux articles sont intéressants, mais je dirais que ce n'est pas une bonne direction pour Go, car Genus est orienté objet, et Go ne l'est pas, et Familia unifie le sous-typage et le polymorphisme paramétrique, et Go n'a ni l'un ni l'autre. Je pense que Go devrait simplement adopter soit le polymorphisme paramétrique, soit la quantification universelle, il n'a pas besoin de sous-typage, et à mon avis, c'est un meilleur langage pour ne pas l'avoir.

Je pense que Go devrait rechercher des génériques qui ne nécessitent pas d'orientation objet et ne nécessitent pas de sous-typage. Go a déjà des interfaces, qui je pense sont un bon mécanisme pour les génériques. Si vous pouvez voir que Go interfaces == c++ concepts == Haskell type-classes, il me semblerait que la façon d'ajouter des génériques tout en gardant la saveur de 'Go' serait d'étendre les interfaces pour prendre plusieurs paramètres de type (je dirais comme les types associés sur les interfaces aussi, mais cela pourrait être une extension distincte de celui-ci aide à faire accepter plusieurs paramètres de type). Ce serait le changement clé, mais pour activer cela, il faudrait une syntaxe `` alternative '' pour les interfaces dans les signatures de fonction, afin que vous puissiez obtenir les multiples paramètres de type vers les interfaces, c'est là que toute la syntaxe des crochets angulaires entre en jeu .

Les interfaces Go ne sont pas des classes de types - ce sont simplement des types - mais l'unification des interfaces avec des classes de types est ce que Familia montre comment faire. Les mécanismes de Genus et Familia ne sont pas liés au fait que les langages soient entièrement orientés objet. Les interfaces Go rendent déjà Go "orienté objet" de la manière qui compte, donc je pense que les idées pourraient être adaptées sous une forme légèrement simplifiée.

@andrewcmyers

Les interfaces Go ne sont pas des classes de types - ce sont simplement des types

Ils ne se comportent pas comme des types pour moi, car ils permettent le polymorphisme. L'objet dans un tableau polymorphe comme Addable[] a toujours son type réel (visible par réflexion à l'exécution), ils se comportent donc exactement comme des classes de type à paramètre unique. Le fait qu'ils soient mis à la place d'un type dans les signatures de type est simplement une notation abrégée omettant la variable de type. Ne confondez pas la notation avec la sémantique.

f(x : Addable) == f<T>(x : T) requires Addable<T>

Cette identité n'est bien sûr valable que pour les interfaces à paramètre unique.

La seule différence significative entre les interfaces et les classes de type à paramètre unique est que les interfaces sont définies localement, mais cela est utile car cela évite le problème de cohérence globale que Haskell a avec ses classes de type. Je pense que c'est un point intéressant dans l'espace de conception. Les interfaces multiparamètres vous donneraient toute la puissance des classes de types multiparamètres avec l'avantage d'être locales. Il n'est pas nécessaire d'ajouter d'héritage ou de sous-typage au langage Go (qui sont les deux caractéristiques clés qui définissent OO je pense).

A MON HUMBLE AVIS:

Avoir toujours un type par défaut serait préférable à un DSL dédié à l'expression des restrictions de type. Comme avoir une fonction f(s T fmt.Stringer) qui est une fonction générique qui accepte tout type qui est aussi/satisfait l'interface fmt.Stringer .

De cette façon, il est possible d'avoir une fonction générique comme :

func add(a, b T int) T int {
    return a + b
}

Désormais, la fonction add() fonctionne avec n'importe quel type T qui, comme int s, prend en charge l'opérateur + .

@dc0d Je suis d'accord que cela semble attrayant en regardant la syntaxe actuelle de Go. Cependant, il n'est pas « complet » dans la mesure où il ne peut pas représenter toutes les contraintes nécessaires aux génériques, et il y aura toujours une poussée pour l'étendre davantage. Il en résultera une prolifération de syntaxes différentes que je considère comme en conflit avec l'objectif de simplicité. Mon point de vue est que la simplicité n'est pas simple, elle doit être la plus simple tout en offrant la puissance expressive requise. Actuellement, je vois que la principale limitation de Go dans la puissance expressive générique est le manque d'interfaces multi-paramètres. Par exemple, une interface Collection pourrait être définie comme :

type T U Collection interface {
   member(c T, v U) Bool
   insert(c T, v U) T
}

Cela a donc du sens, n'est-ce pas ? Nous aimerions écrire des interfaces sur des choses comme des collections. La question est donc de savoir comment utiliser cette interface dans une fonction. Ma suggestion serait quelque chose comme:

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
}

La syntaxe n'est qu'une suggestion cependant, peu m'importe quelle est la syntaxe, tant que vous pouvez exprimer ces concepts dans le langage.

@keean Ce ne serait pas exact si je disais que la syntaxe ne me dérange pas du tout. Mais le but était de mettre l'accent sur le fait d'avoir un type par défaut pour chaque paramètre générique. En ce sens, l'exemple d'interface fourni deviendra :

type Collection interface (T interface{}, U interface{}) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

Maintenant, la partie (T interface{}, U interface{}) aide à définir les contraintes. Par exemple, si les membres sont censés satisfaire fmt.Stringer , alors la définition serait :

type Collection interface (T fmt.Stringer, U fmt.Stringer) {
   member(c T, v U) Bool
   insert(c T, v U) T
}

@dc0d Ce serait à nouveau restrictif dans le sens où vous souhaitez contraindre par plus d'un paramètre de type, considérez:

type OrderedCollection[T, U] interface
   requires Collection[T, U], Ord[U] {...}

Je pense voir où vous voulez en venir avec le placement des paramètres, vous pourriez avoir :

type OrderedCollection interface(T, U)
   requires Collection(T, U), Ord(U) {...}

Comme je l'ai dit, je ne suis pas trop préoccupé par la syntaxe, car je peux m'habituer à la plupart des syntaxes. D'après ce qui précède, je suppose que vous préférez les parenthèses '()' pour les interfaces multi-paramètres.

@keean Considérons l'interface heap.Interface . La définition actuelle dans la bibliothèque standard est :

type Interface interface {
    sort.Interface
    Push(x interface{}) // add x as element Len()
    Pop() interface{}   // remove and return element Len() - 1.
}

Réécrivons-la maintenant comme une interface générique, en utilisant le type par défaut :

type Interface interface (T interface{}) {
    sort.Interface
    Push(x T) // add x as element Len()
    Pop() T   // remove and return element Len() - 1.
}

Cela ne casse aucune des séries de codes Go 1.x là-bas. Une implémentation serait ma proposition pour Type Alias ​​Rebinding. Mais je suis sûr qu'il peut y avoir de meilleures implémentations.

Avoir des types par défaut nous permet d'écrire du code générique qui peut être utilisé avec le code de style Go 1.x. Et la bibliothèque standard peut devenir générique, sans rien casser. C'est une grande victoire IMO.

@dc0d donc vous suggérez une amélioration progressive ? Ce que vous suggérez me semble bien comme une amélioration progressive, mais il a encore un pouvoir expressif générique limité. Comment implémenteriez-vous les interfaces "Collection" et "OrderedCollection" ?

Considérez que plusieurs extensions de langage partielles peuvent conduire à un produit final plus complexe (avec plusieurs syntaxes alternatives) que la mise en œuvre de la solution complète de la manière la plus simple possible.

@keean Je ne comprends pas la partie requires Collection[T, U], Ord[U] . Comment restreignent-ils les paramètres de type T et U ?

@dc0d Ils fonctionnent de la même manière que dans une fonction, mais s'appliquent à tout. Ainsi, pour toute paire de types TU qui est une OrderedCollection, nous exigeons que TU soit également une instance de Collection et que U soit Ord. Ainsi, partout où nous utilisons OrderedCollection, nous pouvons utiliser les méthodes de Collection et Ord, le cas échéant.

Si nous sommes minimalistes, elles ne sont pas nécessaires, car nous pouvons inclure les interfaces supplémentaires dans les types de fonctions où nous en avons besoin, par exemple :

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

Mais c'est peut-être plus lisible :

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) Tant qu'il y a une valeur par défaut obligatoire pour les paramètres de type, je me sens heureux. De cette façon, il est possible de maintenir la compatibilité descendante avec la série de codes Go 1.x. C'est le point principal que j'ai essayé de faire valoir.

@keean

Les interfaces Go ne sont pas des classes de types - ce sont simplement des types

Ils ne se comportent pas comme des types pour moi, car ils permettent le polymorphisme.

Oui, ils autorisent le polymorphisme de sous-type . Go a un sous-typage via les types d'interface. Il n'a pas de hiérarchies de sous-types explicitement déclarées, mais c'est largement orthogonal. Ce qui fait que Go n'est pas entièrement orienté objet, c'est le manque d'héritage.

Vous pouvez également afficher les interfaces comme des applications existentiellement quantifiées de classes de type. Je crois que c'est ce que vous avez en tête. C'est ce que nous avons fait dans Genus et Familia.

@andrewcmyers

Oui, ils permettent le polymorphisme de sous-type.

Aller aussi loin que je sache est invariant, il n'y a pas de covariance ou de contravariance, cela indique fortement qu'il ne s'agit pas de sous-typage. Les systèmes de types polymorphes sont invariants, il me semble donc que Go est plus proche de ce modèle, et traiter les interfaces comme des classes de types à paramètre unique semble plus conforme à la simplicité de Go. L'absence de covariance et de contravariance est un grand avantage pour les génériques, il suffit de regarder la confusion que de telles choses créent dans des langages comme C# :

https://docs.microsoft.com/en-us/dotnet/standard/generics/covariance-and-contravariance

Je pense que Go devrait totalement éviter ce genre de complexité. Pour moi, cela signifie que nous ne voulons pas de génériques et de sous-typages dans le même système de typage.

Vous pouvez également afficher les interfaces comme des applications existentiellement quantifiées de classes de type. Je crois que c'est ce que vous avez en tête. C'est ce que nous avons fait dans Genus et Familia.

Parce que Go a des informations de type au moment de l'exécution, il n'y a pas besoin de quantification existentielle. Dans Haskell, les types sont déballés (comme les types 'C' natifs) et cela signifie qu'une fois que nous avons mis quelque chose dans une collection existentielle, nous ne pouvons pas (facilement) récupérer le type du contenu, tout ce que nous pouvons faire est d'utiliser les interfaces fournies (type-classes ). Ceci est mis en œuvre en stockant un pointeur vers les interfaces à côté des données brutes. Dans Go, le type de données est stocké à la place, les données sont 'Boxed' (comme dans C# boxed et unboxed data). En tant que tel, Go n'est pas limité aux seules interfaces stockées avec les données car il est possible (par l'utilisation d'un type-case) de récupérer le type des données dans la collection, ce qui n'est possible que dans Haskell en implémentant un 'Reflection' typeclass (bien que difficile d'extraire les données, il est possible de sérialiser le type et les données, pour dire des chaînes, puis de désérialiser en dehors de la boîte existentielle). Donc, la conclusion que j'ai est que les interfaces Go se comportent exactement comme les classes de type le feraient, si Haskell fournissait la classe de type 'Reflection' en tant que fonction intégrée. En tant que tel, il n'y a pas de boîte existentielle et nous pouvons toujours saisir la casse sur le contenu des collections, mais les interfaces se comportent exactement comme des classes de types. La différence entre Haskell et Go réside dans la sémantique des données en boîte et non en boîte, et les interfaces sont des classes de type à paramètre unique. En effet, lorsque 'Go' traite une interface comme un type, ce qu'il fait réellement est :

Addable[] == exists T . T[] requires Addable[T], Reflection[T]

Il est probablement intéressant de noter que c'est de la même manière que "Trait Objects" fonctionne dans Rust.

Go peut totalement éviter les existentiels (étant visibles pour le programmeur), la covariance et la contravariance ce qui est une bonne chose, et cela rendra les génériques beaucoup plus simples et plus puissants à mon avis.

Aller aussi loin que je sache est invariant, il n'y a pas de covariance ou de contravariance, cela indique fortement qu'il ne s'agit pas de sous-typage.

Les systèmes de types polymorphes sont invariants, donc cela me semble plus proche de ce modèle, et traiter les interfaces comme des classes de types à paramètre unique semble plus conforme à la simplicité de Go.

Puis-je suggérer que vous avez tous les deux raison ? En cela, les interfaces sont équivalentes aux classes de types, mais les classes de types sont une forme de sous-typage. Les définitions de sous-typage que j'ai trouvées jusqu'à présent sont toutes assez vagues et imprécises et se résument à "A est un sous-type de B, si l'un peut être remplacé par l'autre". Ce qui, IMO, peut être assez facilement soutenu pour être satisfait par les classes de type .

Notez que l'argument variance en lui-même ne fonctionne pas vraiment à l'OMI. La variance est une propriété des constructeurs de types, pas un langage. Et il est assez normal que tous les constructeurs de type d'un langage ne soient pas des variants (par exemple, de nombreux langages avec sous-typage ont des tableaux modifiables, qui doivent être invariants pour être de type sûr). Je ne vois donc pas pourquoi vous ne pourriez pas avoir de sous-typage sans constructeurs de types variants.

De plus, je pense que cette discussion est un peu trop large pour un problème sur le référentiel Go. Il ne devrait pas s'agir de discuter des subtilités des théories des types, mais de savoir si et comment ajouter des génériques à Go.

@Merovius Variance est une propriété associée au sous-typage. Dans les langues sans sous-typage, il n'y a pas de variance. Pour qu'il y ait variance en premier lieu, vous devez avoir un sous-typage, qui introduit le problème de covariance/contravariance aux constructeurs de type. Vous avez raison cependant que dans un langage avec sous-typage, il est possible d'avoir tous les constructeurs de types invariants.

Les classes de types ne sont certainement pas des sous-typages, car une classe de types n'est pas un type. Cependant, nous pouvons voir les «types d'interface» dans Go comme ce que Rust appelle un «objet de trait», en fait un type dérivé de la classe de types.

La sémantique de Go semble correspondre à l'un ou l'autre modèle pour le moment, car elle n'a pas de variance et elle a des «objets de trait» implicites. Alors peut-être que Go est à un point de basculement, les génériques et le système de type pourraient être développés dans le sens du sous-typage, introduisant de la variance et aboutissant à quelque chose comme les génériques en C#. Alternativement, Go pourrait introduire des interfaces multi-paramètres, permettant des interfaces pour les collections, ce qui romprait le lien immédiat entre les interfaces et les "types d'interface". Par exemple si vous avez :

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

Il n'y a plus de relation de sous-type évidente entre les types T, U et l'interface Collection. Ainsi, vous ne pouvez voir la relation entre le type d'instance et les types d'interface que comme sous-typage pour le cas particulier des interfaces à paramètre unique, et nous ne pouvons pas exprimer des abstractions de choses comme des collections avec des interfaces à paramètre unique.

Je pense que pour les génériques, vous devez clairement être capable de modéliser des choses comme des collections, donc les interfaces multi-paramètres sont un must pour moi. Cependant, je pense que l'interaction entre la covariance et la contravariance dans les génériques crée un système de type trop complexe, donc je voudrais éviter le sous-typage.

@keean Étant donné que les interfaces peuvent être utilisées comme types et que les classes de types ne sont pas des types, l'explication la plus naturelle de la sémantique Go est que les interfaces ne sont pas des classes de types. Je comprends que vous préconisez de généraliser les interfaces en tant que classes de types ; Je pense que c'est une direction raisonnable de prendre la langue, et en fait nous avons déjà largement exploré cette approche dans nos travaux publiés.

Pour savoir si Go a un sous-typage, veuillez considérer le code suivant :

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

L'affectation de x à y démontre que le type de y peut être utilisé là où le type de x est attendu. Il s'agit d'une relation de sous-typage, à savoir : CloneableZ <: Cloneable , et aussi S <: CloneableZ . Même si vous expliquiez les interfaces en termes de classes de types, il y aurait toujours une relation de sous-typage en jeu ici, quelque chose comme S <: ∃T.CloneableZ[T] <: ∃T.Cloneable[T] .

Notez qu'il serait parfaitement sûr pour Go d'autoriser la fonction Clone à renvoyer un S , mais il se trouve que Go applique des règles inutilement restrictives pour la conformité aux interfaces : en fait, les mêmes règles que Java appliqué à l'origine. Le sous-typage ne nécessite pas de constructeurs de type non invariants, comme l'a observé @Merovius .

@andrewcmyers Que se passe-t-il avec les interfaces multi-paramètres, comme celles nécessaires aux collections abstraites ?

De plus, l'affectation de x à y peut être considérée comme démontrant l'héritage d'interface sans aucun sous-typage. En Haskell (qui n'a clairement pas de sous-typage), vous écririez :

class Cloneable t => CloneableZ t where...

Où nous avons x est un type qui implémente CloneableZ qui, par définition, implémente également Cloneable , donc peut évidemment être assigné à y .

Pour essayer de résumer, vous pouvez soit voir une interface comme un type et Go pour avoir un sous-typage limité sans constructeurs de type covariant ou contravariant, soit vous pouvez la voir comme un "objet trait", ou peut-être que dans Go nous l'appellerions un " interface object", qui est en fait un conteneur polymorphe contraint par une interface "typeclass". Dans le modèle de classe de types, il n'y a pas de sous-typage, et donc aucune raison d'avoir à penser à la covariance et à la contravariance.

Si nous nous en tenons au modèle de sous-typage, nous ne pouvons pas avoir de types de collection, c'est pourquoi C++ a dû introduire des modèles, car le sous-typage orienté objet n'est pas suffisant pour définir de manière générique des concepts comme les conteneurs. Nous nous retrouvons avec deux mécanismes d'abstraction, objets et sous-typage, et modèles/traits et génériques, et les interactions entre les deux deviennent complexes, regardez C++, C# et Scala par exemple. Il y aura des appels continus pour introduire des constructeurs covariants et contravariants pour augmenter la puissance des génériques, conformément à ces autres langages.

Si nous voulons des collections génériques sans introduire un système de génériques séparé, alors nous devrions penser à des interfaces comme des classes de types. Les interfaces multi-paramètres signifieraient ne plus penser au sous-typage, mais plutôt penser à l'héritage d'interface. Si nous voulons améliorer les génériques dans Go et autoriser les abstractions de choses comme les collections, et que nous ne voulons pas la complexité des systèmes de types de langages comme C++, C#, Scala, etc., alors les interfaces multiparamètres et l'héritage d'interface sont le moyen aller.

@keean

Que se passe-t-il avec les interfaces multi-paramètres, comme celles nécessaires pour abstraire les collections ?

Veuillez consulter nos articles sur Genus et Familia, qui prennent en charge les contraintes de type multiparamètres. Familia unifie ces contraintes avec des interfaces et permet aux interfaces de contraindre plusieurs types.

Si nous nous en tenons au modèle de sous-typage, nous ne pouvons pas avoir de types de collection

Je ne suis pas tout à fait sûr de ce que vous entendez par "le modèle de sous-typage", mais il est assez clair que Java et C # ont des types de collection, donc cette affirmation n'a pas beaucoup de sens pour moi.

Où nous avons x est un type qui implémente CloneableZ qui, par définition, implémente également Cloneable, donc peut évidemment être affecté à y.

Non, dans mon exemple, x est une variable et y est une autre variable. Si je sais que y est un type CloneableZ et que x est un type Cloneable , cela ne signifie pas que je peux attribuer de y à x. C'est ce que fait mon exemple.

Pour clarifier que le sous-typage est nécessaire pour modéliser Go, vous trouverez ci-dessous une version affinée de l'exemple dont l'équivalent moral ne vérifie pas le type dans Haskell. L'exemple montre que le sous-typage permet la création de collections hétérogènes dans lesquelles différents éléments ont des implémentations différentes. De plus, l'ensemble des implémentations possibles est ouvert.

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

Je ne suis pas tout à fait sûr de ce que vous entendez par "le modèle de sous-typage", mais il est assez clair que Java et C # ont des types de collection, donc cette affirmation n'a pas beaucoup de sens pour moi.

Regardez pourquoi C++ a développé des modèles, le modèle de sous-typage OO n'était pas capable d'exprimer les concepts génériques nécessaires pour généraliser des choses comme les collections. C # et Java ont également dû introduire un système générique complet séparé des objets, du sous-typage et de l'héritage, puis ont dû nettoyer le gâchis des interactions complexes des deux systèmes avec des choses comme les constructeurs de types covariants et contravariants. Avec le recul, nous pouvons éviter le sous-typage OO et regarder à la place ce qui se passe si nous ajoutons des interfaces (classes de types) à un langage simplement typé. C'est ce que Rust a fait, il vaut donc la peine d'y jeter un coup d'œil, mais bien sûr, c'est compliqué par toute la durée de vie. Go a GC donc il n'aurait pas cette complexité. Ma suggestion est que Go peut être étendu pour permettre des interfaces multi-paramètres et éviter cette complexité.

Concernant votre affirmation selon laquelle vous ne pouvez pas faire cet exemple dans Haskell, voici le 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)

Quelques différences intéressantes, Go dérive automatiquement ce type data Cloneable = forall a . (ICloneable a, Show a) => ToCloneable a car c'est ainsi que vous transformez une interface (qui n'a pas de stockage) en un type (qui a du stockage), Rust dérive également ces types et les appelle "objets de trait" . Dans d'autres langages comme Java, C# et Scala, nous constatons que vous ne pouvez pas instancier les interfaces, ce qui est en fait "correct", les interfaces ne sont pas des types, elles n'ont pas de stockage, Go dérive automatiquement le type d'un conteneur existentiel pour vous afin que vous puissiez traiter l'interface comme un type, et Go vous le cache en donnant au conteneur existentiel le même nom que l'interface dont il est dérivé. L'autre chose à noter est que ce [2]Cloneable{x, y} contraint tous les membres à Cloneable , alors que Haskell n'a pas de telles coercitions implicites, et nous devons explicitement contraindre les membres avec ToCloneable .

On m'a également fait remarquer que nous ne devrions pas considérer les sous-types S et T de Cloneable parce que S et T ne sont pas structurellement compatibles. Nous pouvons littéralement déclarer n'importe quel type une instance de Cloneable (juste en déclarant la définition pertinente de la fonction clone dans Go) et ces types n'ont aucune relation entre eux.

La plupart des propositions de génériques semblent inclure des jetons supplémentaires qui, à mon avis, nuisent à la lisibilité et à la simple sensation de Go. Je voudrais proposer une syntaxe différente qui, je pense, pourrait bien fonctionner avec la grammaire existante de Go (il arrive même que la syntaxe soit assez bien mise en évidence dans Github Markdown).

Les points principaux de la proposition :

• La grammaire de Go semble toujours avoir un moyen simple de déterminer quand une déclaration de type s'est terminée car nous recherchons un jeton ou un mot-clé spécifique. Si cela est vrai dans tous les cas, les arguments de type peuvent simplement être ajoutés à la suite des noms de type eux-mêmes.
• Comme la plupart des propositions, le même identifiant signifie le même type dans toute déclaration de fonction. Ces identifiants n'échappent jamais à la déclaration.
• Dans la plupart des propositions, vous devez déclarer des arguments de type générique, mais dans cette proposition, c'est implicite. Certaines personnes prétendront que cela nuit à la lisibilité ou à la clarté (l'implicite est mauvaise), ou limite la capacité de nommer un type, les réfutations suivent :
  
  
  
  • Quand il s'agit de nuire à la lisibilité, je pense que vous pouvez le discuter dans les deux sens, le plusou [T] nuit tout autant à la lisibilité en faisant beaucoup de bruit syntaxique.
  
  
  • L'implicite, lorsqu'elle est utilisée correctement, peut aider une langue à être moins verbeuse. Nous élidons les déclarations de type avec := tout le temps parce que les informations cachées par cela ne sont tout simplement pas assez importantes pour être épelées à chaque fois.
  
  
  • Nommer un type concret (non générique) a ou t est probablement une mauvaise pratique, donc cette proposition suppose qu'il est sûr de réserver ces identifiants pour agir comme arguments de type générique. Bien que cela nécessiterait peut-être une migration go fix?
  
  

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
}

Ceci est tiré d'un Gist qui contient un peu plus de détails ainsi que des types de somme proposés ici : https://gist.github.com/aarondl/9b950373642fcf5072942cf0fca2c3a2

Ce n'est pas une proposition de génériques complètement débusquée et ce n'est pas censé l'être, il y a beaucoup de problèmes à résoudre pour pouvoir ajouter des génériques à Go. Celui-ci ne traite que de la syntaxe, et j'espère que nous pourrons avoir une conversation pour savoir si ce qui est proposé est faisable/souhaitable.

@aarondl
Cela me semble bien, en utilisant cette syntaxe, nous aurions:

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 Pourriez-vous s'il vous plaît expliquer un peu le type Collection . Je n'arrive pas à comprendre :

type Collection a b interface {
   member(c a, e b) Bool
   insert(c a, e b) a
}

@dc0d Collection est une interface qui résume _toutes_ les collections, donc les arbres, les listes, les tranches, etc., nous pouvons donc avoir des opérations génériques comme member et insert qui fonctionneront sur n'importe quelle collection contenant n'importe quel type de données. Dans ce qui précède, j'ai donné l'exemple de la définition de 'insert' pour le type LinkedList dans l'exemple précédent :

func insert(c *LinkedList a, e a) *LinkedList a {
   c.Append(e)
   return c
}

On pourrait aussi le définir pour une tranche

func insert(c []a, e a) []a {
   return append(c, e)
}

Cependant, nous n'avons même pas besoin du type de fonctions paramétriques avec des variables de type comme illustré par @aarondl avec le type polymorphe a pour que cela fonctionne, car vous pouvez simplement définir pour les types concrets :

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

Donc Collection est une interface pour généraliser à la fois le type d'un conteneur et le type de son contenu, permettant d'écrire des fonctions génériques qui fonctionnent sur toutes les combinaisons de conteneur et de contenu.

Il n'y a aucune raison pour que vous ne puissiez pas également avoir une tranche de collections []Collection où le contenu serait tous différents types de collection avec différents types de valeurs, à condition member et insert aient été définis pour chaque combinaison .

@aarondl Étant donné que type LinkedList a est déjà une déclaration de type valide, je ne vois que deux façons de rendre cette analyse analysable sans ambiguïté: Rendre la grammaire sensible au contexte (entrer dans les problèmes d'analyse C, ugh) ou utiliser une anticipation illimitée ( ce que la grammaire go a tendance à éviter, à cause des mauvais messages d'erreur en cas d'échec). Je comprends peut-être mal quelque chose, mais l'OMI qui s'oppose à une approche sans jeton.

@keean Les interfaces dans Go utilisent des méthodes, pas des fonctions. Dans la syntaxe spécifique que vous avez suggérée, rien n'attache insert à *LinkedList pour le compilateur (dans Haskell, cela se fait via des déclarations instance ). Il est également normal que les méthodes modifient la valeur sur laquelle elles opèrent. Rien de tout cela n'est un Show-Stopper, soulignant simplement que la syntaxe que vous suggérez ne fonctionne pas bien avec Go. Probablement plus quelque chose comme

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

Ce qui démontre également quelques questions supplémentaires sur la façon dont les paramètres de type sont définis et comment cela doit être analysé.

@aarondl il y a aussi plus de questions que j'aurais sur votre proposition. Par exemple, il n'autorise pas les contraintes, vous n'obtenez donc qu'un polymorphisme sans contrainte. Ce qui, en général, n'est pas vraiment utile, car vous n'êtes pas autorisé à faire quoi que ce soit avec les valeurs que vous obtenez (par exemple, vous ne pouvez pas implémenter Collection avec une carte, car tous les types ne sont pas des clés de carte valides). Que devrait-il se passer lorsque quelqu'un essaie de faire quelque chose comme ça ? S'il s'agit d'une erreur de compilation, se plaint-il de l'instanciation (messages d'erreur C++ à venir) ou de la définition (vous ne pouvez pratiquement rien faire, car rien ne fonctionne avec tous les types) ?

@keean Je n'arrive toujours pas à comprendre comment a est limité à une liste (ou une tranche ou toute autre collection). S'agit-il d'une grammaire spéciale dépendante du contexte pour les collections ? Si oui quelle est sa valeur ? Il n'est pas possible de déclarer des types définis par l'utilisateur de cette manière.

@Merovius Cela signifie-t-il que Go ne peut pas effectuer d'envois multiples et rend le premier argument d'une "fonction" spécial? Cela suggère que les types associés seraient mieux adaptés que les interfaces à paramètres multiples. Quelque chose comme ça:

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

Cependant, cela pose toujours des problèmes car rien n'oblige les deux collections à être du même type ... Vous auriez besoin de quelque chose comme:

func[A] useIt(c A, e A.Element) requires A:Collection

Pour tenter d'expliquer la différence, les interfaces multiparamètres ont des types _input_ supplémentaires qui participent à la sélection d'instance (d'où la connexion avec la répartition multiple), alors que les types associés sont des types _output_, seul le type récepteur participe à la sélection d'instance, puis les types associés dépendent du type de récepteur.

@dc0d a et b sont des paramètres de type de l'interface, tout comme dans une classe de type Haskell. Pour que quelque chose soit considéré comme un Collection , il doit définir les méthodes qui correspondent aux types dans l'interface où a et b peuvent être de n'importe quel type. Cependant, comme @Merovius l' a souligné, les interfaces Go sont basées sur des méthodes et ne prennent pas en charge la répartition multiple, de sorte que les interfaces multiparamètres peuvent ne pas convenir. Avec le modèle de méthode à envoi unique de Go, avoir des types associés dans les interfaces, au lieu de plusieurs paramètres, semblerait être un meilleur ajustement. Cependant, l'absence de répartition multiple rend difficile l'implémentation de fonctions comme unify(x, y) , et vous devez utiliser le modèle de répartition double qui n'est pas très agréable.

Pour expliquer un peu plus la chose multi-paramètres:

type Cloneable[A] interface {
   clone(x A) A
}

Ici, a représente n'importe quel type, peu importe ce que c'est, tant que les fonctions correctes sont définies, nous le considérons comme Cloneable . Nous considérerions les interfaces comme des contraintes sur les types plutôt que les types eux-mêmes.

func clone(x int) int {...}

ainsi, dans le cas de 'clone', nous remplaçons a par int dans la définition de l'interface, et nous pouvons appeler clone si la substitution réussit. Cela correspond bien à cette notation :

func[A] test(x A) A requires Cloneable[A] {...}

Cela équivaut à :

type Cloneable interface {
   clone() Cloneable
}

mais déclare une fonction et non une méthode et peut être étendue avec plusieurs paramètres. Si vous avez un langage avec répartition multiple, le premier argument d'une fonction/méthode n'a rien de spécial, alors pourquoi l'écrire à un endroit différent.

Comme Go n'a pas d'envoi multiple, tout cela commence à sembler trop difficile à changer d'un coup. Il semble que les types associés seraient mieux adaptés, bien que plus limités. Cela permettrait des collections abstraites, mais pas des solutions élégantes à des choses comme l'unification.

@Merovius Merci d'avoir jeté un coup d'œil à la proposition. Permettez-moi d'essayer de répondre à vos préoccupations. Je suis triste que vous ayez rejeté la proposition avant que nous en discutions davantage, j'espère que je pourrai changer d'avis - ou peut-être que vous pourrez changer le mien :)

Anticipation illimitée :
Donc, comme je l'ai mentionné dans la proposition, il semble actuellement que la grammaire Go ait un bon moyen de détecter syntaxiquement la "fin" de presque tout. Et nous le ferions encore à cause des arguments génériques implicites. Une seule lettre minuscule étant la construction syntaxique qui crée cet argument générique - ou tout ce que nous décidons de faire de ce jeton en ligne, peut-être même nous rabattons-nous sur une chose symbolisée comme @a dans la proposition si nous aimons suffisamment la syntaxe mais ce n'est pas le cas possible étant donné la difficulté du compilateur sans jetons, bien que la proposition perde beaucoup de charme dès que vous faites cela.

Quoi qu'il en soit, le problème avec type LinkedList a sous cette proposition n'est pas si difficile car nous savons que a est un argument de type générique et donc cela échouerait avec une erreur de compilation identique à type LinkedList échoue aujourd'hui avec : prog.go:3:16: expected type, found newline (and 1 more errors) . Le message d'origine n'est pas vraiment sorti et le dit, mais vous n'êtes plus autorisé à nommer un type concret [a-z]{1} qui, je pense, résout ce problème et est un sacrifice avec lequel je pense que nous serions tous d'accord making (je ne vois que des inconvénients dans la création de types réels avec des noms à une seule lettre dans le code Go aujourd'hui).

C'est juste du polymorphisme sans contrainte
La raison pour laquelle j'ai omis tout type de traits ou de contraintes d'arguments génériques est que je pense que c'est le rôle des interfaces dans Go, si vous souhaitez faire quelque chose avec une valeur, cette valeur doit être un type d'interface et non un type entièrement générique. Je pense que cette proposition fonctionne bien avec les interfaces aussi.

Selon cette proposition, nous aurions toujours le même problème qu'actuellement avec des opérateurs tels que + , vous ne pourriez donc pas créer de fonction d'ajout générique pour tous les types numériques, mais vous pourriez accepter une fonction d'ajout générique comme argument. Considérer ce qui suit:

func Sort(slice []a, compare func (a, a) bool) { ... }

Questions sur la portée

Tu as donné un exemple ici :

type Collection e interface {
    Element(e) book
    Insert(e)
}

func (l *(LinkedList e)) Element(el e) book {
    // ...
}

func (l* (LinkedList e)) Insert(el e) {
    // ...
}

En règle générale, la portée de ces identifiants est liée à la déclaration/définition particulière dans laquelle ils se trouvent. Ils ne sont partagés nulle part et je ne vois aucune raison pour qu'ils le soient.

@keean C'est très intéressant bien que, comme d'autres l'ont souligné, vous deviez modifier ce que vous avez montré pour pouvoir implémenter les interfaces (actuellement, dans votre exemple, il n'y a pas de méthodes avec des récepteurs, uniquement des fonctions). J'essaie de réfléchir davantage à la façon dont cela affecte ma proposition initiale.

Une seule lettre minuscule étant la construction syntaxique qui crée cet argument générique

Je ne me sens pas bien à ce sujet; cela nécessite d'avoir des productions séparées pour ce qu'est un identifiant en fonction du contexte et signifie également interdire arbitrairement certains identifiants pour les types. Mais ce n'est pas vraiment le moment de parler de ces détails.

Dans le cadre de cette proposition, nous aurions toujours le même problème qu'actuellement avec des opérateurs tels que +

Je ne comprends pas cette phrase. Actuellement, l'opérateur + n'a aucun de ces problèmes, car les types de ses opérandes sont connus localement et le message d'erreur est clair et sans ambiguïté et indique la source du problème. Ai-je raison de supposer que vous dites que vous souhaitez interdire toute utilisation de valeurs génériques qui n'est pas autorisée pour tous les types possibles (je ne peux pas penser à beaucoup d'opérations de ce type) ? Et créer une erreur de compilation pour l'expression incriminée dans la fonction générique ? OMI qui limiterait trop la valeur des génériques.

si vous souhaitez faire quelque chose avec une valeur, cette valeur doit être un type d'interface et non un type entièrement générique.

Les deux principales raisons pour lesquelles les gens veulent des génériques sont les performances (éviter l'encapsulation des interfaces) et la sécurité des types (s'assurer que le même type est utilisé à différents endroits, sans se soucier de savoir lequel). Cela semble ignorer ces raisons.

vous pouvez accepter une fonction d'ajout générique comme argument.

Vrai. Mais assez peu ergonomique. Considérez le nombre de plaintes concernant l'API sort . Pour de nombreux conteneurs génériques, le nombre de fonctions que l'appelant devrait implémenter et transmettre semble prohibitif. Considérez, à quoi ressemblerait une implémentation container/heap dans le cadre de cette proposition et en quoi serait-elle meilleure que l'implémentation actuelle, en termes d'ergonomie ? Il semblerait que les gains soient négligeables ici, au mieux. Vous devriez implémenter plus de fonctions triviales (et dupliquer vers/référencer sur chaque site d'utilisation), pas moins.

@Merovius

penser à ce point de @aarondl

vous pouvez accepter une fonction d'ajout générique comme argument.

Il serait préférable d'avoir une interface Addable pour permettre la surcharge de l'addition, étant donné une certaine syntaxe pour définir les opérateurs infixes :

type Addable interface {
   + (x Addable, y Addable) Addable
}

Malheureusement, cela ne fonctionne pas, car cela n'exprime pas que nous nous attendons à ce que tous les types soient identiques. Pour définir addable, nous aurions besoin de quelque chose comme les interfaces multi-paramètres :

type Addable[A] interface {
   + (x A, y A) A
}

Ensuite, vous auriez également besoin de Go pour effectuer une répartition multiple, ce qui signifierait que tous les arguments d'une fonction sont traités comme un récepteur pour la correspondance d'interface. Ainsi, dans l'exemple ci-dessus, tout type est Addable s'il y a une fonction + définie dessus qui satisfait les définitions de fonction dans la définition d'interface.

Mais compte tenu de ces changements, vous pouvez maintenant écrire :

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

Bien sûr, la surcharge de fonctions et la distribution multiple peuvent être quelque chose que les gens ne veulent jamais dans Go, mais des choses comme définir l'arithmétique de base sur des types définis par l'utilisateur comme les vecteurs, les matrices, les nombres complexes, etc., seront toujours impossibles. Comme je l'ai dit ci-dessus, les "types associés" sur les interfaces permettraient une certaine augmentation de la capacité de programmation générique, mais pas une généralité complète. L'envoi multiple (et probablement la surcharge de fonctions) est-il quelque chose qui pourrait arriver dans Go ?

des choses comme définir l'arithmétique de base sur des types définis par l'utilisateur comme les vecteurs, les matrices, les nombres complexes, etc., seront toujours impossibles.

Certains pourraient considérer qu'il s'agit d'une fonctionnalité :) AFAIR, il y a une proposition ou un fil flottant quelque part pour discuter de l'opportunité. FWIW, je pense que c'est - encore une fois - un hors-sujet errant. La surcharge d'opérateurs (ou les idées générales "comment faire Go plus Haskell") n'est pas vraiment le but de ce problème :)

L'envoi multiple (et probablement la surcharge de fonctions) est-il quelque chose qui pourrait arriver dans Go ?

Ne jamais dire jamais. Je ne m'y attendais pas, personnellement.

@Merovius

Certains pourraient considérer cela comme une fonctionnalité :)

Bien sûr, et si Go ne le fait pas, il y a d'autres langues qui le feront :-) Go ne doit pas être tout pour tout le monde. J'essayais juste d'établir une certaine portée pour les génériques dans Go. Mon objectif est de créer des langages entièrement génériques, car j'ai une aversion pour la répétition et le passe-partout (et je n'aime pas les macros). Si j'avais un centime pour chaque fois que j'ai dû écrire une liste chaînée ou un arbre en 'C' pour un type de données spécifique. Cela rend en fait certains projets impossibles pour une petite équipe en raison du volume de code qui doit être conservé dans votre tête pour le comprendre, puis maintenu au fil des modifications. Parfois, je pense que les gens qui n'ont pas besoin de génériques n'ont tout simplement pas encore écrit un programme assez important. Bien sûr, vous pouvez à la place avoir une grande équipe de développeurs travaillant sur quelque chose et n'avoir que chaque développeur responsable d'une petite partie du code total, mais je suis intéressé à rendre un développeur unique (ou une petite équipe) aussi efficace que possible.

Étant donné que la surcharge de fonctions et l'envoi multiple sont hors de portée, et compte tenu également des problèmes d'analyse avec la suggestion de @ aarondl , il semble que l'ajout de types associés aux interfaces et de paramètres de type aux fonctions serait à peu près aussi loin que vous voudriez go avec des génériques dans Go.

Quelque chose comme ça semblerait être le bon genre de chose:

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

Ensuite, il y aurait une décision dans l'implémentation d'utiliser des types paramétriques ou des types universellement quantifiés. Avec les types paramétriques (comme Java), une fonction "générique" n'est pas réellement une fonction mais une sorte de modèle de fonction de type sécurisé, et en tant que tel ne peut pas être passé comme argument à moins que son paramètre de type ne soit fourni ainsi :

f(useIt) // not okay with parametric types
f(useIt<List>) // okay with parametric types

Avec les types universellement quantifiés, vous pouvez passer useIt comme argument, et il peut ensuite être fourni avec un paramètre de type à l'intérieur f . La raison de privilégier les types paramétriques est que vous pouvez monomorphiser le polymorphisme au moment de la compilation, ce qui signifie qu'il n'y a pas d'élaboration de fonctions polymorphes au moment de l'exécution. Je ne suis pas sûr que ce soit un problème avec Go, car Go effectue déjà la distribution d'exécution sur les interfaces, donc tant que le paramètre de type pour useIt implémente Collection, vous pouvez envoyer au bon récepteur au moment de l'exécution, donc universel la quantification est probablement la bonne voie pour le Go.

Je me demande, SFINAE mentionné uniquement par @bcmills. Pas même mentionné dans la proposition (bien que Sort soit là comme exemple).
À quoi pourrait ressembler alors le Sort pour la tranche et la liste liée ?

@keean
Je n'arrive pas à comprendre comment on définirait une collection générique "Slice" avec votre suggestion. Vous semblez définir un 'IntSlice' qui pourrait implémenter 'Collection' (bien que Insert renvoie un type différent de celui recherché par l'interface), mais ce n'est pas une 'tranche' générique, car cela semble être uniquement pour ints , et les implémentations de méthode ne concernent que les ints. Doit-on définir une implémentation spécifique par type ?

Parfois, je pense que les gens qui n'ont pas besoin de génériques n'ont tout simplement pas encore écrit un programme assez important.

Je peux vous assurer que cette impression est fausse. Et FWIW, ISTM que "l'autre côté" met "ne pas voir le besoin" dans le même seau que "ne pas voir l'utilité". J'en vois l'utilité et ne le réfute pas. Je n'en vois pourtant pas vraiment la nécessité . Je me débrouille bien sans, même dans les grandes bases de code.

Et ne confondez pas non plus "vouloir qu'elles soient bien faites et indiquer où les propositions existantes ne le sont pas" avec "s'opposer fondamentalement à l'idée même".

également compte tenu des problèmes d'analyse avec la suggestion de @ aarondl .

Comme je l'ai dit, je ne pense pas que parler du problème d'analyse soit vraiment productif en ce moment. Les problèmes d'analyse peuvent être résolus. Le manque de polymorphisme contraint est beaucoup plus grave, sémantiquement. IMO, ajouter des génériques sans cela ne vaut vraiment pas la peine.

@urandom

Je n'arrive pas à comprendre comment on définirait une collection générique "Slice" avec votre suggestion.

Comme indiqué ci-dessus, vous auriez toujours besoin de définir une implémentation distincte pour chaque type de tranche, mais vous gagneriez toujours à pouvoir écrire des algorithmes en termes d'interface générique. Si vous souhaitez autoriser une implémentation générique pour toutes les tranches, vous devez autoriser les types et méthodes paramétriques associés. Notez que j'ai déplacé le paramètre de type après le mot-clé afin qu'il se produise avant le type de récepteur.

type<T> []T.Element = Int

func<T> ([]T) Member(e T) Bool {...}
func<T> ([]T) Insert(e T) Collection {...}

Cependant, maintenant, vous devez également gérer la spécialisation, car quelqu'un pourrait définir le type et les méthodes associés pour les []int plus spécialisés et vous devrez décider lequel utiliser. Normalement, vous iriez avec l'instance la plus spécifique, mais cela ajoute une autre couche de complexité.

Je ne sais pas combien cela vous rapporte réellement. Avec mon exemple original ci-dessus, vous pouvez écrire des algorithmes génériques pour agir sur des collections générales à l'aide de l'interface, et vous n'auriez qu'à fournir les méthodes et les types associés pour les types que vous utilisez réellement. La principale victoire pour moi est de pouvoir définir des algorithmes comme le tri sur des collections arbitraires et de mettre ces algorithmes dans une bibliothèque. Si j'ai ensuite une liste de "formes", il me suffit de définir les méthodes d'interface de collection pour ma liste de formes, et je peux ensuite utiliser n'importe quel algorithme de la bibliothèque sur celles-ci. Être capable de définir les méthodes d'interface pour tous les types de tranches m'intéresse moins, et pourrait être trop complexe pour Go ?

@Merovius

Mais je n'en vois pas vraiment la nécessité. Je me débrouille bien sans, même dans les grandes bases de code.

Si vous pouvez faire face à un programme de 100 000 lignes, vous pourrez faire plus avec 100 000 lignes génériques qu'avec 100 000 lignes non génériques (en raison de la répétition). Ainsi, vous pouvez être un développeur super-star capable de gérer de très grandes bases de code, mais vous obtiendriez toujours plus avec une très grande base de code générique car vous élimineriez la redondance. Ce programme générique se transformerait en un programme non générique encore plus vaste. Il me semble juste que vous n'avez pas encore atteint votre limite de complexité.

Cependant, je pense que vous avez raison, le "besoin" est trop fort, j'écris volontiers du code go, avec seulement une frustration occasionnelle à propos du manque de génériques, et je peux contourner ce problème en écrivant simplement plus de code, et dans Go ce code est agréablement direct et littéral.

L'absence de polymorphisme contraint est beaucoup plus grave, sémantiquement. IMO, ajouter des génériques sans cela ne vaut vraiment pas la peine.

Je suis d'accord avec ça.

vous pourrez faire plus avec 100 000 lignes génériques qu'avec 100 000 lignes non génériques (à cause de la répétition)

Je suis curieux, d'après votre exemple hypothétique, quel % de ces lignes serait une fonction générique ?
D'après mon expérience, c'est moins de 2% (à partir d'une base de code avec 115k LOC), donc je ne pense pas que ce soit un bon argument sauf si vous écrivez une bibliothèque pour les "collections"

Je souhaite que nous ayons finalement des génériques

@keean

Concernant votre affirmation selon laquelle vous ne pouvez pas faire cet exemple dans Haskell, voici le code :

Ce code n'est pas moralement équivalent au code que j'ai écrit. Il introduit un nouveau type de wrapper Cloneable en plus de l'interface ICloneable. Le code Go n'avait pas besoin d'un wrapper ; ni d'autres langues qui prennent en charge le sous-typage.

@andrewcmyers

Ce code n'est pas moralement équivalent au code que j'ai écrit. Il introduit un nouveau type de wrapper Cloneable en plus de l'interface ICloneable.

N'est-ce pas ce que fait ce code :

type Cloneable interface {...}

Il introduit un data-type 'Cloneable' dérivé de l'interface. Vous ne voyez pas le 'ICloneable' parce que vous n'avez pas de déclarations d'instance pour les interfaces, vous déclarez simplement les méthodes.

Peut-on considérer qu'il s'agit d'un sous-typage lorsque les types qui implémentent une interface n'ont pas besoin d'être structurellement compatibles ?

@keean Je considérerais Cloneable n'est qu'un type, pas vraiment un "type de données". Dans un langage comme Java, il n'y aurait pratiquement aucun coût supplémentaire à l'abstraction Cloneable , car il n'y aurait pas de wrapper, contrairement à votre code.

Il me semble limité et indésirable d'exiger une similitude structurelle entre les types implémentant une interface, donc je suis confus quant à ce que vous pensez ici.

@andrewcmyers
J'utilise le type et le type de données de manière interchangeable. Tout type pouvant contenir des données est un type de données.

car il n'y aurait pas de wrapper, contrairement à votre code.

Il y a toujours un wrapper car les types Go sont toujours encadrés, donc le wrapper existe autour de tout. Haskell a besoin que le wrapper soit explicite car il a des types non encadrés.

similitude structurelle entre les types implémentant une interface, donc je ne comprends pas ce que vous pensez ici.

Le sous-typage structurel exige que les types soient « structurellement compatibles ». Comme il n'y a pas de hiérarchie de type explicite comme dans un langage OO avec héritage, le sous-typage ne peut pas être nominal, il doit donc être structurel, s'il existe.

Je vois cependant ce que vous voulez dire, que je décrirais comme considérant une interface comme une classe de base abstraite, pas une interface, avec une sorte de relation de sous-type nominal implicite avec tout type qui implémente les méthodes requises.

Je pense en fait que Go convient aux deux modèles en ce moment, et cela pourrait aller dans les deux sens à partir d'ici, mais je suggérerais que l'appeler une interface et non une classe suggère une façon de penser sans sous-typage.

@keean Je ne comprends pas votre commentaire. D'abord, vous me dites que vous n'êtes pas d'accord et que je "n'ai tout simplement pas encore atteint ma limite de complexité", puis vous me dites que vous êtes d'accord (en ce sens que "besoin" est un mot trop fort). Je pense aussi que votre argument est fallacieux (vous supposez que LOC est la principale mesure de complexité et que chaque ligne de code est égale). Mais surtout, je ne pense pas que "qui écrit des programmes plus compliqués" soit vraiment une ligne de discussion productive. J'essayais juste de clarifier que l'argument "si vous n'êtes pas d'accord avec moi, cela doit signifier que vous ne travaillez pas sur des problèmes aussi difficiles ou intéressants" n'est pas convaincant et n'est pas de bonne foi. J'espère que vous pouvez simplement croire que les gens peuvent être en désaccord avec vous sur l'importance de cette fonctionnalité tout en étant tout aussi compétents et en faisant des choses tout aussi intéressantes.

@merovius
Je disais que vous êtes probablement un programmeur plus compétent que moi, et donc capable de travailler avec plus de complexité. Je ne pense certainement pas que vous travailliez sur des problèmes moins intéressants ou moins complexes, et je suis désolé que cela se soit passé ainsi. J'ai passé la journée d'hier à essayer de faire fonctionner un scanner, ce qui était un problème très inintéressant.

Je peux penser que les génériques m'aident à écrire des programmes plus complexes avec ma capacité intellectuelle limitée, et aussi admettre que je n'ai pas "besoin" des génériques. C'est une question de degré. Je peux toujours programmer sans génériques, mais je ne peux pas nécessairement écrire des logiciels de la même complexité.

J'espère que cela vous rassure j'agis de bonne foi, je n'ai pas d'agenda caché ici, et si Go n'adopte pas les génériques je continuerai à l'utiliser. J'ai une opinion sur la meilleure façon de faire des génériques, mais ce n'est pas la seule opinion, je ne peux parler que de ma propre expérience. Si je n'aide pas, il y a beaucoup d'autres choses sur lesquelles je peux passer mon temps, alors dites juste un mot, et je me recentrerai ailleurs.

@Merovius Merci pour la poursuite du dialogue.

| Les deux principales raisons pour lesquelles les gens veulent des génériques sont les performances (éviter l'encapsulation des interfaces) et la sécurité des types (s'assurer que le même type est utilisé à différents endroits, sans se soucier de savoir lequel). Cela semble ignorer ces raisons.

Peut-être que nous examinons ce que j'ai proposé de manière très différente, car de mon point de vue, cela fait ces deux choses pour autant que je sache? Dans l'exemple de liste chaînée, il n'y a pas d'encapsulation avec les interfaces et elle devrait donc être aussi performante que si elle était écrite à la main pour un type donné. Du côté de la sécurité du type, c'est la même chose. Y a-t-il un contre-exemple que vous pouvez donner ici pour m'aider à comprendre d'où vous venez ?

| Vrai. Mais assez peu ergonomique. Considérez le nombre de plaintes concernant l'API de tri. Pour de nombreux conteneurs génériques, le nombre de fonctions que l'appelant devrait implémenter et transmettre semble prohibitif. Considérez, à quoi ressemblerait une implémentation de conteneur/tas dans le cadre de cette proposition et en quoi serait-elle meilleure que l'implémentation actuelle, en termes d'ergonomie ? Il semblerait que les gains soient négligeables ici, au mieux. Vous devriez implémenter plus de fonctions triviales (et dupliquer vers/référencer sur chaque site d'utilisation), pas moins.

En fait, je ne suis pas du tout concerné par cela. Je ne crois pas que le nombre de fonctions serait prohibitif, mais je suis définitivement ouvert à voir des contre-exemples. Rappelez-vous que l'API dont les gens se sont plaints n'était pas celle pour laquelle vous deviez fournir une fonction mais celle d'origine ici : https://golang.org/pkg/sort/#Interface où vous deviez créer un nouveau type qui était simplement votre tranche + type, puis implémentez 3 méthodes dessus. À la lumière des plaintes et de la douleur associées à cette interface, ce qui suit a été créé : https://golang.org/pkg/sort/#Slice , pour ma part, je n'ai aucun problème avec cette API et nous récupérerions les pénalités de performance de celle-ci dans le cadre de la proposition dont nous discutons en modifiant simplement la définition en func Slice(slice []a, less func(a, a) bool) .

En termes de structure de données container/heap , quelle que soit la proposition générique que vous acceptez et qui nécessite une réécriture complète. container/heap tout comme le package sort fournit simplement des algorithmes au-dessus de votre propre structure de données, mais aucun package ne possède jamais la structure de données car sinon nous aurions []interface{} et le les coûts associés à cela. Vraisemblablement, nous les changerions puisque vous pourriez avoir un Heap qui possède une tranche avec un type concret grâce aux génériques, et cela est vrai dans toutes les propositions que j'ai vues ici (y compris la mienne) .

J'essaie de démêler les différences dans nos points de vue sur ce que j'ai proposé. Et je pense que la racine du désaccord (au-delà de toute préférence personnelle syntaxiquement) est qu'il n'y a pas de contraintes sur les types génériques. Mais j'essaie toujours de comprendre ce que cela nous rapporte. Si la réponse est que rien en matière de performances n'est autorisé à utiliser une interface, alors je ne peux pas dire grand-chose ici.

Considérez la définition de table de hachage suivante :

// 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) { ... }

Sommes-nous en train de dire que le []Hasher est un non-démarreur en raison de problèmes de performances/de stockage et que pour avoir une implémentation réussie de Generics dans Go, nous devons absolument avoir quelque chose comme ce qui suit ?

// 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) { ... }

J'espère que vous voyez où je veux en venir. Mais il est tout à fait possible que je ne comprenne pas les contraintes que vous souhaitez imposer à certains codes. Peut-être qu'il y a des cas d'utilisation que je n'ai pas pris en compte, quoi qu'il en soit j'espère arriver à une meilleure compréhension de ce que sont les exigences et de la façon dont la proposition leur échoue.

Peut-être que nous examinons ce que j'ai proposé de manière très différente, car de mon point de vue, cela fait ces deux choses pour autant que je sache?

Le "ceci" dans la section que vous citez fait référence à l'utilisation d'interfaces. Le problème n'est pas que votre proposition ne le fasse pas non plus, c'est que votre proposition n'autorise pas le polymorphisme contraint, ce qui exclut la plupart de ses utilisations. Et l'alternative que vous avez suggérée pour cela était les interfaces, qui ne traitent pas vraiment non plus le cas d'utilisation principal des génériques (à cause des deux choses que j'ai mentionnées).

Par exemple, votre proposition (telle qu'écrite à l'origine) ne permettait pas d'écrire une carte générique de quelque sorte que ce soit, car cela nécessiterait de pouvoir au moins comparer les clés en utilisant == (ce qui est une contrainte, donc implémenter un map nécessite un polymorphisme contraint).

À la lumière des plaintes et de la douleur associées à cette interface, ce qui suit a été créé : https://golang.org/pkg/sort/#Slice

Notez que cette interface n'est toujours pas possible dans votre proposition de génériques, car elle repose sur la réflexion pour la longueur et l'échange (donc, encore une fois, vous avez une contrainte sur les opérations de tranche). Même si nous acceptons cette API comme la limite inférieure de ce que les génériques devraient pouvoir accomplir (beaucoup de gens ne le feraient pas. Il y a encore beaucoup de plaintes concernant le manque de sécurité de type dans cette API), votre proposition ne passerait pas cette barre.

Mais aussi, encore une fois, vous citez une réponse à un point spécifique que vous avez soulevé, à savoir que vous pourriez obtenir un polymorphisme contraint en passant des littéraux de fonction dans l'API. Et cette manière spécifique que vous avez suggérée pour contourner le manque de polymorphisme contraint nécessiterait la mise en œuvre plus ou moins de l'ancienne API. c'est-à-dire que vous citez ma réponse à cet argument, que vous ne faites que répéter :

nous récupérerions les pénalités de performance de cela dans le cadre de la proposition dont nous discutons en modifiant simplement la définition en func Slice(slice []a, less func(a, a) bool).

C'est l'ancienne API cependant. Vous dites "ma proposition n'autorise pas le polymorphisme contraint, mais ce n'est pas un problème, car nous pouvons tout simplement ne pas utiliser de génériques et utiliser à la place les solutions existantes (réflexion/interfaces)". Eh bien, répondre à "votre proposition ne permet pas les cas d'utilisation les plus élémentaires pour lesquels les gens veulent des génériques" par "nous pouvons simplement faire ce que les gens font déjà sans génériques pour ces cas d'utilisation les plus élémentaires" ne semble pas nous comprendre n'importe où, TBH. Une proposition de génériques qui ne vous aide pas à écrire même les types de conteneurs de base, sort, max… ne semble tout simplement pas en valoir la peine.

cela est vrai dans toutes les propositions que j'ai vues ici (y compris la mienne).

La plupart des propositions génériques incluent un moyen de contraindre les paramètres de type. c'est-à-dire pour exprimer "le paramètre de type doit avoir une méthode Less", ou "le paramètre de type doit être comparable". Le vôtre - AFAICT - ne le fait pas.

Considérez la définition de table de hachage suivante :

Votre définition est incomplète. a) Le type de clé a également besoin d'égalité et b) vous n'empêchez pas l'utilisation de différents types de clé. c'est-à-dire que ce serait légal:

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)

Cela ne devrait cependant pas être légal, car vous utilisez différents types de clés. c'est-à-dire que le conteneur n'est pas vérifié par type dans la mesure où les gens le souhaitent. Vous devez paramétrer la table de hachage sur le type de clé et de valeur

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

Ou, si cela vous aide, imaginez que vous essayez d'implémenter un ensemble de hachage. Vous auriez le même problème, mais maintenant le conteneur résultant n'a pas de vérification de type supplémentaire sur interface{} .

C'est pourquoi votre proposition n'aborde pas les cas d'utilisation les plus élémentaires : elle s'appuie sur des interfaces pour limiter le polymorphisme, mais ne fournit en fait aucun moyen de vérifier la cohérence de ces interfaces. Vous pouvez soit avoir une vérification de type cohérente, soit avoir un polymorphisme contraint, mais pas les deux. Mais vous avez besoin des deux.

que pour avoir une implémentation réussie de Generics dans Go, nous devons absolument avoir quelque chose comme ce qui suit ?

C'est du moins ce que je ressens à ce sujet, ouais, à peu près. Si une proposition ne permet pas d'écrire des conteneurs de type sécurisé ou de trier ou… cela n'ajoute vraiment rien au langage existant qui soit suffisamment important pour justifier le coût.

@Merovius D'accord. Je pense avoir compris ce que tu veux. Gardez à l'esprit que vos cas d'utilisation sont très éloignés de ce que je veux. Je n'ai pas vraiment envie de conteneurs sûrs, bien que je soupçonne - comme vous l'avez dit - que cela puisse être une opinion minoritaire. Quelques-unes des choses les plus importantes que j'aimerais voir sont des types de résultats au lieu d'erreurs et une manipulation facile des tranches sans duplication ni réflexion partout où ma proposition fait un travail raisonnable. Cependant, je peux voir comment, de votre point de vue, cela "ne traite pas les cas d'utilisation les plus élémentaires" si votre cas d'utilisation de base consiste à écrire des conteneurs génériques sans utiliser d'interfaces,

Notez que cette interface n'est toujours pas possible dans votre proposition de génériques, car elle repose sur la réflexion pour la longueur et l'échange (donc, encore une fois, vous avez une contrainte sur les opérations de tranche). Même si nous acceptons cette API comme la limite inférieure de ce que les génériques devraient pouvoir accomplir (beaucoup de gens ne le feraient pas. Il y a encore beaucoup de plaintes concernant le manque de sécurité de type dans cette API), votre proposition ne passerait pas cette barre.

En lisant ceci, il est clair que vous avez complètement mal compris la façon dont les tranches génériques fonctionneraient/devraient fonctionner dans le cadre de cette proposition. C'est à travers ce malentendu que vous êtes arrivé à la fausse conclusion que "cette interface n'est toujours pas possible dans votre proposition". Dans toute proposition, une tranche générique doit être possible, c'est ce que je pense. Et len() dans le monde tel que je l'ai vu serait défini comme suit : func len(slice []a) , qui est un argument de tranche générique, ce qui signifie qu'il peut compter la longueur sans réflexion pour n'importe quelle tranche. C'est en grande partie l'intérêt de cette proposition comme je l'ai dit ci-dessus (manipulation facile des tranches) et je suis désolé de ne pas avoir été en mesure de bien transmettre cela à travers les exemples que j'ai donnés et l'essentiel que j'ai fait. Une tranche générique devrait pouvoir être utilisée aussi facilement qu'un []int l'est aujourd'hui, je répète que toute proposition qui ne traite pas cela (slice/array swaps, assignation, len, cap, etc. ) est insuffisant à mon avis.

Cela dit, nous savons maintenant clairement quels sont les objectifs de chacun. Quand j'ai proposé ce que j'ai fait j'ai bien dit que c'était simplement une proposition syntaxique et que les détails étaient super flous. Mais nous sommes entrés dans les détails de toute façon et l'un de ces détails a fini par être le manque de contraintes, quand je l'ai écrit, je ne les avais tout simplement pas à l'esprit car ils ne sont pas importants pour ce que j'aimerais faire , cela ne veut pas dire que nous ne pouvons pas les ajouter ou qu'ils ne sont pas souhaitables. Le principal problème de continuer avec la syntaxe proposée et d'essayer d'introduire des contraintes serait que la définition d'un argument générique se répète actuellement (intentionnellement), de sorte qu'il n'y a pas de référence au code ailleurs pour déterminer les contraintes, etc. Si nous devions introduire des contraintes, je ne vois pas comment on pourrait garder ça.

Le meilleur contre-exemple est cette fonction de tri dont nous parlions plus tôt.

type Sort(slice []a:Lesser, less func(a:Lesser, a:Lesser)) { ... }

Comme vous pouvez le voir, il n'y a pas de bon moyen d'y parvenir, et les approches de jeton de spam pour les génériques recommencent à sonner mieux. Afin de définir des contraintes sur ceux-ci, nous devons changer deux choses par rapport à la proposition d'origine :

• Il doit y avoir un moyen de pointer vers un argument de type et de lui donner des contraintes.
• Les contraintes doivent durer plus longtemps qu'une seule définition, peut-être que cette portée est un type, peut-être que cette portée est un fichier (le fichier semble en fait assez raisonnable).

Avis de non-responsabilité : ce qui suit n'est pas un véritable amendement à la proposition, car je lance simplement des symboles aléatoires, j'utilise simplement ces syntaxes comme exemples pour illustrer ce que nous pourrions faire pour modifier la proposition telle qu'elle est à l'origine.

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

Encore une fois, notez qu'aucun des éléments ci-dessus que je ne souhaite vraiment ajouter à la proposition. Je montre simplement quel type de constructions nous pourrions utiliser pour résoudre le problème, et leur apparence est quelque peu hors de propos pour le moment.

La question à laquelle nous devons alors répondre est la suivante : tirons-nous toujours profit des arguments génériques implicites ? Le point principal de la proposition était de garder la sensation propre de Go-like du langage, de garder les choses simples, de garder les choses suffisamment silencieuses en éliminant les jetons excessifs. Dans les nombreux cas où aucune contrainte n'est nécessaire, par exemple une fonction de carte ou la définition d'un type de résultat, est-ce que ça a l'air bien, est-ce que ça ressemble à Go, est-ce utile ? En supposant que les contraintes sont également disponibles sous une forme ou une autre.

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 Je vais essayer d'expliquer. La raison pour laquelle vous avez besoin de contraintes de type est que c'est la seule façon d'appeler des fonctions ou des méthodes sur un type. considérez le type sans contrainte a quel type cela peut-il être, eh bien cela pourrait être une chaîne ou un Int ou quoi que ce soit. Nous ne pouvons donc pas appeler de fonctions ou de méthodes dessus car nous ne connaissons pas le type. Nous pourrions utiliser un changement de type et une réflexion d'exécution pour obtenir le type, puis appeler des fonctions ou des méthodes dessus, mais c'est quelque chose que nous voulons éviter avec les génériques. Lorsque vous contraignez un type, par exemple a est un animal, nous pouvons alors appeler n'importe quelle méthode définie pour un animal sur a .

Dans votre exemple, oui, vous pouvez transmettre une fonction de mappage, mais cela se traduira par des fonctions prenant beaucoup d'arguments, et est fondamentalement comme un langage sans interfaces, juste des fonctions de première classe. Passer chaque fonction que vous allez utiliser sur le type a va obtenir une très longue liste de fonctions dans n'importe quel programme réel, surtout si vous écrivez principalement du code générique pour l'injection de dépendances, ce que vous voulez faire pour minimiser le couplage.

Par exemple, que se passe-t-il si la fonction qui appelle map est également générique ? Que se passe-t-il si la fonction qui appelle est générique, etc. Comment définissons-nous le mappeur si nous ne connaissons pas encore le type de a ?

func m(slice []a) []b {
   mapper := func(x a) b {...}
   return map(slice, mapper)
}

Quelles fonctions pouvons-nous appeler sur x lorsque nous essayons de définir mapper ?

@keean Je comprends le but et la fonction des contraintes. Je ne les apprécie tout simplement pas autant que des choses simples comme les structures de conteneurs génériques (et non les conteneurs génériques pour ainsi dire) et les tranches génériques et ne les ai donc même pas incluses dans la proposition d'origine.

Je crois toujours que les interfaces sont la bonne réponse à des problèmes comme celui dont vous parlez où vous faites l'injection de dépendances, cela ne semble tout simplement pas être le bon endroit pour les génériques, mais qui suis-je pour dire. Le chevauchement entre leurs responsabilités est assez important à mes yeux, d'où la raison pour laquelle @Merovius et moi avons dû discuter pour savoir si nous pouvions ou non vivre sans eux, et il m'a à peu près convaincu qu'ils seraient utiles dans certains cas d'utilisation, donc je exploré un peu ce que nous pourrions faire pour ajouter la fonctionnalité à la proposition que j'avais initialement faite.

Quant à votre exemple, vous ne pouvez appeler aucune fonction sur x. Mais vous pouvez toujours opérer sur la tranche comme n'importe quelle autre tranche qui est extrêmement utile en elle-même. Vous ne savez pas non plus quelle est la fonction à l'intérieur de la fonction ... peut-être vouliez-vous attribuer à un var?

@aarondl
Merci, j'ai corrigé la syntaxe, mais je pense que le sens était toujours clair.

Les exemples que j'ai donnés ci-dessus utilisaient à la fois le polymorphisme paramétrique et les interfaces pour atteindre un certain niveau de programmation générique, mais l'absence de répartition multiple plafonnera toujours le niveau de généralité réalisable. En tant que tel, il semble que Go ne fournira pas les fonctionnalités que je recherche dans une langue, cela ne signifie pas que je ne peux pas utiliser Go pour certaines tâches, et en fait je le suis déjà et cela fonctionne bien, même si j'ai eu au code copier-coller qui n'a vraiment besoin que d'une seule définition. J'espère juste qu'à l'avenir, si ce code doit être modifié, le développeur pourra en trouver toutes les instances collées.

Je suis alors dans deux esprits quant à savoir si la généralité limitée possible sans de si grands changements dans la langue est une bonne idée, compte tenu de la complexité que cela ajoutera. Peut-être que Go vaut mieux rester simple, et les gens peuvent ajouter des macros comme le prétraitement, ou d'autres langages qui compilent en Go, pour fournir ces fonctionnalités ? D'autre part, l'ajout de polymorphisme paramétrique serait une bonne première étape. Permettre à ces paramètres de type d'être contraints serait une bonne prochaine étape. Ensuite, vous pourriez ajouter des paramètres de type associés aux interfaces, et vous auriez quelque chose de raisonnablement générique, mais c'est probablement tout ce que vous pouvez obtenir sans envoi multiple. En les divisant en fonctionnalités plus petites, je suppose que vous augmenteriez les chances de les faire accepter ?

@keean
L'expédition multiple est-elle nécessaire ? Très peu de langues le supportent nativement. Même C++ ne le supporte pas. C# le supporte un peu via dynamic mais je ne l'ai jamais utilisé dans la pratique et le mot-clé en général est très très rare dans le code réel. Les exemples dont je me souviens traitent de quelque chose comme l'analyse JSON, pas l'écriture de génériques.

L'expédition multiple est-elle nécessaire ?

À mon humble avis, je pense que @keean parle de répartition multiple statique fournie par les classes de types/interfaces.
Ceci est même fourni en C++ par surcharge de méthode (je ne sais pas pour C#)

Ce que vous voulez dire, c'est la distribution multiple dynamique qui est assez lourde dans les langages statiques sans types d'union. Les langages dynamiques contournent ce problème en omettant la vérification de type statique (inférence de type partielle pour les langages dynamiques, identique pour le type "dynamique" de C#).

Un type pourrait-il être fourni comme "juste" un paramètre ?

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 a écrit :

Un type pourrait-il être fourni comme "juste" un paramètre ?

On peut se demander dans quelle mesure cela serait possible ou souhaité en aller

Ce que vous voulez pourrait être réalisé à la place si les contraintes génériques sont prises en charge :

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)

Cela devrait également être possible avec des contraintes:

func convert(value s) t requires Convertible<s,t>{
    return t(value);
}

f:float64:=2.0

i:int64=convert(f)

Pour ce que ça vaut, notre langage Genus prend en charge l'envoi multiple. Les modèles d'une contrainte peuvent fournir plusieurs implémentations qui sont distribuées.

Je comprends que la notation Convertible<s,t> est nécessaire pour la sécurité du temps de compilation, mais pourrait peut-être être dégradée en une vérification d'exécution

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)

Mais cela ressemble plus à du sucre de syntaxe pour reflect .

@Inuart , le compilateur peut vérifier que le type implémente la classe de types au moment de la compilation, de sorte que la vérification de l'exécution n'est pas nécessaire. L'avantage est une meilleure performance (ce que l'on appelle l'abstraction à coût zéro). S'il s'agit d'une vérification d'exécution, vous pouvez également utiliser reflect .

@creker

L'expédition multiple est-elle nécessaire ?

Je suis trop dans l'esprit à ce sujet. D'une part, l'envoi multiple (avec des classes de types multi-paramètres) ne fonctionne pas bien avec les existentiels, ce que 'Go' appelle des 'valeurs d'interface'.

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

Nous ne pouvons pas définir la tranche de Equals car nous n'avons aucun moyen d'indiquer que le paramètre de droite provient de la même collection. Nous ne pouvons même pas faire cela dans Haskell :

data Equals = forall a . IEquals a a => Equals a

Ce n'est pas bon car cela ne permet qu'à un type d'être comparé à lui-même

data Equals = forall a b . IEquals a b => Equals a

Ce n'est pas bon car nous n'avons aucun moyen de contraindre b à être un autre existentiel dans la même collection que a (si a even est dans une collection).

Cependant, il est très facile d'étendre avec un nouveau type :

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

Et ce serait encore plus concis avec des instances par défaut ou une spécialisation.

D'autre part, nous pouvons réécrire ceci dans 'Go' qui fonctionne en ce moment :

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

Cela fonctionne bien avec l'existentiel (valeur d'interface), mais c'est beaucoup plus complexe, plus difficile de voir ce qui se passe et comment cela fonctionne, et il y a la grande restriction que nous avons besoin d'une interface par type et nous devons coder en dur l'acceptable types de côté droit comme celui-ci :

type EqualsRight interface {
    EqualsInt
    EqualsFloat
}

Ce qui signifie que nous devrions modifier la source de la bibliothèque pour ajouter un nouveau type car l'interface EqualsRight n'est pas extensible.

Ainsi, sans interfaces multi-paramètres, nous ne pouvons pas définir d'opérateurs génériques extensibles comme l'égalité. Avec les interfaces multiparamètres, les existentiels (valeurs d'interface) deviennent problématiques.

Mon principal problème avec un grand nombre des syntaxes proposées (syntaces ?) Blah[E] est que le type sous-jacent ne montre aucune information sur le contenu des génériques.

Par exemple:

type Comparer[C] interface {
    Compare(other C) bool
}
// or
type Comparer c interface {
    Compare(other c) bool
}
...

Cela signifie que nous déclarons un nouveau type qui ajoute plus d'informations sur le type sous-jacent. Le but de la déclaration type n'est-il pas de définir un nom basé sur un autre type ?

Je proposerais une syntaxe plus dans le sens de

type Comparer interface[C] {
    Compare(other C) bool
}

Cela signifie que vraiment Comparer est juste un type basé sur interface[C] { ... } , et interface[C] { ... } est bien sûr son propre type distinct de interface { ... } . Cela vous permet d'utiliser une interface générique sans la nommer, si vous le souhaitez (ce qui est autorisé avec les interfaces normales). Je pense que cette solution est un peu plus intuitive et fonctionne bien avec le système de type de Go, mais corrigez-moi si je me trompe.

Remarque : La déclaration d'un type générique ne serait autorisée que sur les interfaces, les structures et les fonctions avec les syntaxes suivantes :
interface[G] { ... }
struct[G] { ... }
func[G] (vars...) { ... }

Ensuite, "implémenter" les génériques aurait les syntaxes suivantes :
interface[G] { ... }[string]
struct[G] { ... }[string]
func[G] (vars...) { ... }[int](args...)

Et avec quelques exemples pour le rendre un peu plus clair :

Interfaces

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

Structures

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

Les fonctions

func[A] AddManyTo(a Adder[A], many ...A) {
    for _, each := range a {
        a.Add(each)
    }
}

Ceci est en réponse au projet de contrats Go2 et j'utiliserai sa syntaxe, mais je le poste ici car il s'applique à toute proposition de polymorphisme paramétrique.

L'incorporation de paramètres de type ne devrait pas être autorisée.

Envisager

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.

pour un type arbitraire R et un contrat arbitraire C qui ne contient pas Foo() .

T aura tous les sélecteurs requis par C mais une instanciation particulière de T peut également avoir d'autres sélecteurs arbitraires, y compris Foo .

Disons que Bar est une structure, admissible sous C , qui a un champ nommé Foo .

X(Bar) pourrait être une instanciation illégale. Sans un moyen de spécifier le contrat selon lequel un type n'a pas de sélecteur, cela devrait être une propriété déduite.

Les méthodes de X(Bar) pourraient continuer à résoudre les références à Foo comme X(Bar).R.Foo . Cela rend possible l'écriture du type générique, mais pourrait prêter à confusion pour un lecteur non familiarisé avec la tatillonne des règles de résolution. En dehors des méthodes de X , le sélecteur resterait ambigu donc, alors que interface { Foo() } ne dépend pas des paramètres de X , certaines instanciations de X pas le satisfaire.

Interdire l'intégration d'un paramètre de type est plus simple.

(Si cela doit être autorisé, cependant, le nom du champ serait T pour la même raison que le nom du champ d'un S intégré défini comme type S = io.Reader est S et non Reader mais aussi parce que le type instanciant T n'a pas nécessairement besoin d'avoir un nom du tout.)

@jimmyfrasche Je pense que les champs intégrés avec des types génériques sont suffisamment utiles pour qu'il soit bon de les autoriser, même s'il peut y avoir un peu de maladresse par endroits. Ma suggestion serait de supposer dans tout code générique que le type intégré a défini tous les champs et méthodes possibles à tous les niveaux possibles, de sorte que dans le code générique, toutes les méthodes et champs intégrés de types non génériques soient effacés.

Donc donné :

type R struct(type T) {
    io.Reader
    T
}

les méthodes sur R ne pourraient pas invoquer Read sur R sans passer par Reader. Par example:

func (r R) Do() {
     r.Read(buf)     // Illegal
     r.Reader.Read(buf)  // ok
}

Le seul inconvénient que je peux voir est que le type dynamique peut contenir plus de membres que le type statique. Par example:

func (r R) Do() {
    var x interface{} = r
    x.(io.Reader)    // Succeeds
}

@rogpeppe

Le seul inconvénient que je peux voir est que le type dynamique peut contenir plus de membres que le type statique.

C'est le cas avec les paramètres de type directement, donc je pense que cela devrait également convenir avec les types paramétriques. Je pense que la solution au problème présenté par @jimmyfrasche pourrait être de mettre l'ensemble de méthodes souhaité du type paramétré dans le contrat.

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.

Cela permettrait à Foo d'être appelé directement sur X . Bien sûr, cela irait à l'encontre de la règle "pas de noms locaux dans les contrats"...

@stevenblenkinsop Hmm, il est possible, si gênant, de le faire sans se référer à X

contract C(t T) {
  struct{ R; T }{}.Foo
}

C est toujours lié à l'implémentation de X bien qu'un peu plus vaguement.

Si vous ne le faites pas et que vous écrivez

func (x X(T)) Fooer() interface { Foo() } {
  return x
}

ça compile ? Ce ne serait pas sous la règle de @rogpeppe qui semble devoir être adoptée également lorsque vous ne faites pas la garantie dans le contrat. Mais alors s'applique-t-il uniquement lorsque vous intégrez un argument de type sans contrat suffisant ou pour toutes les intégrations ?

Il serait plus facile de simplement l'interdire.

J'ai commencé à travailler sur cette proposition avant l'annonce du projet Go2.

J'étais prêt à abandonner le mien avec joie quand j'ai vu l'annonce, mais je suis toujours instable face à la complexité du brouillon, alors j'ai terminé le mien. C'est moins puissant mais plus simple. Si rien d'autre, il peut avoir quelques morceaux qui valent la peine d'être volés.

Il développe la syntaxe des propositions précédentes de @ianlancetaylor , car c'est ce qui était disponible lorsque j'ai commencé. Ce n'est pas fondamental. Il pourrait être remplacé par une syntaxe (type T etc. ou quelque chose d'équivalent. J'avais juste besoin d'une syntaxe comme notation pour la sémantique.

Il se trouve ici : https://gist.github.com/jimmyfrasche/656f3f47f2496e6b49e041cd8ac716e4

La règle devrait être que toute méthode promue à partir d'une profondeur supérieure à celle d'un paramètre de type intégré ne peut être appelée que si (1) l'identité de l'argument de type est connue ou (2) la méthode est affirmée être appelable sur le type par le contrat contraignant le paramètre type. Le compilateur pourrait également déterminer les limites supérieure et inférieure de la profondeur qu'une méthode promue doit avoir dans le type externe O et les utiliser pour déterminer si la méthode est appelable sur un type qui incorpore O , c'est-à-dire s'il existe un potentiel de conflit avec d'autres méthodes promues ou non. Quelque chose de similaire s'appliquerait également à tout paramètre de type qui est affirmé avoir des méthodes appelables, où les plages de profondeur des méthodes dans le paramètre de type seraient [0, inf).

L'intégration de paramètres de type semble tout simplement trop utile pour l'interdire complètement. D'une part, il permet une composition transparente, ce que le modèle d'interfaces d'intégration ne permet pas.

J'ai également trouvé une utilisation potentielle dans la définition des contrats. Si vous voulez pouvoir accepter une valeur de type T (qui pourrait être un type de pointeur) qui pourrait avoir des méthodes définies sur *T , et vous voulez pouvoir mettre cette valeur dans une interface, vous ne pouvez pas nécessairement mettre T dans l'interface, puisque les méthodes peuvent être sur *T , et vous ne pouvez pas nécessairement mettre *T dans l'interface parce que T pourrait lui-même être un type pointeur (et donc *T pourrait avoir un jeu de méthodes vide). Cependant, si vous aviez un emballage comme

type Wrapper(type T) { T }

vous pouvez mettre un *Wrapper(T) dans l'interface dans tous les cas si votre contrat indique qu'il satisfait l'interface.

Tu ne peux pas juste faire

type Interface interface {
  SomeMethod(int) error
}

contract MightBeAPointer(t T) {
  Interface(t)
}

func Example(type T MightBeAPointer)(v T) {
  var i Interface = v
  // ...
}

J'essaie de gérer le cas où quelqu'un appelle

type S struct{}
func (s *S) SomeMethod(int) error { ... }
...
var s S
Example(S)(s)

Cela ne fonctionnera pas car S ne peut pas être converti en Interface , seul *S peut.

Évidemment, la réponse pourrait être « ne fais pas ça ». Cependant, la proposition de contrats décrit des contrats tels que :

contract Contract(t T) {
    var _ error = t.SomeMethod(int(0))
}

S satisferait ce contrat en raison de l'adressage automatique, tout comme *S . Ce que j'essaie de résoudre, c'est l'écart de capacité entre les appels de méthode et les conversions d'interface dans les contrats.

Quoi qu'il en soit, c'est un peu une tangente, montrant une utilisation potentielle pour l'intégration de paramètres de type.

En ce qui concerne l'intégration, je pense que "peut être intégré dans une structure" est une autre restriction que les contrats devraient capturer s'ils étaient autorisés.

Envisager:

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
}

type Embedded(type First, Second Embeddable) struct {
        First
        Second
}

// Error: First and Second both provide method Read.
// That must be diagnosed to the Embeddable contract, not the definition of Embedded itself.
type Boom = Embedded(*bytes.Buffer, *strings.Reader)

@bcmills incorporer des types avec des sélecteurs ambigus est autorisé, donc je ne sais pas comment ce contrat est censé être interprété.

Dans tous les cas, si vous n'intégrez que des types connus, c'est bien. Si vous n'intégrez que des paramètres de type, c'est bien. Le seul cas qui devient étrange est lorsque vous intégrez un ou plusieurs types connus ET un ou plusieurs paramètres de type et uniquement lorsque les sélecteurs du ou des types connus et des arguments de type ne sont pas disjoints

@bcmills incorporer des types avec des sélecteurs ambigus est autorisé, donc je ne sais pas comment ce contrat est censé être interprété.

Hum, bon point. Il me manque une contrainte supplémentaire pour déclencher l'erreur.¹

contract Embeddable(type X, Y) {
    type S struct {
        X
        Y
    }
    var _ io.Reader = S{}
}

¹ https://play.golang.org/p/3wSg5aRjcQc

Cela nécessite l'un des X ou Y mais pas les deux pour être un io.Reader . Il est intéressant de noter que le système de contrat est suffisamment expressif pour permettre cela. Je suis content de ne pas avoir à comprendre les règles d'inférence de type pour une telle bête.

Mais là n'est pas vraiment le problème.

C'est quand tu fais

type S (type T C) struct {
  io.Reader
  T
}
func (s *S(T)) X() io.Reader {
  return s
}

Cela devrait échouer à compiler car T pourrait avoir un sélecteur Read moins que C n'ait

struct{ io.Reader; T }.Read

Mais alors, quelles sont les règles lorsque C ne garantit pas que les ensembles de sélecteurs sont disjoints et que S ne fait pas référence aux sélecteurs ? Est-il possible que chaque instanciation S satisfasse une interface à l'exception des types qui créent un sélecteur ambigu ?

Est-il possible que chaque instanciation S satisfasse une interface à l'exception des types qui créent un sélecteur ambigu ?

Oui, cela semble être le cas. Je me demande si cela implique quelque chose de plus profond... 🤔

Je n'ai rien pu construire d'irrémédiablement méchant, mais l'asymétrie est assez désagréable et me met mal à l'aise :

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

Je m'inquiète des messages d'erreur lorsque G0(B) utilise un G1(B) utilise un . . . utilise un Gn(B) et Gn est celui qui provoque l'erreur. . . .

FTR, vous n'avez pas besoin de vous soucier des sélecteurs ambigus pour déclencher des erreurs de type avec l'intégration.

// Error: Duplicate field name Reader
type Boom = Embedded(*bytes.Reader, *strings.Reader)

Vous supposez que le nom du champ intégré est basé sur le type d'argument, alors qu'il est plus probable qu'il s'agisse du nom du paramètre de type intégré. C'est comme lorsque vous intégrez un alias de type et que le nom du champ est l'alias plutôt que le nom du type qu'il alias.

Ceci est en fait spécifié dans le projet de conception dans la section sur les types paramétrés :

Lorsqu'un type paramétré est une structure et que le paramètre de type est incorporé en tant que champ dans la structure, le nom du champ est le nom du paramètre de type, et non le nom de l'argument de type.

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
}

(Remarque : cela fonctionne mal si vous écrivez Lockable(X) dans la déclaration de la méthode : la méthode doit-elle renvoyer lT ou lX ? Peut-être devrions-nous simplement interdire l'intégration d'un paramètre de type dans une structure.)

Je suis juste assis ici sur la touche et j'observe. Mais aussi s'inquiéter un peu.

Une chose que je ne suis pas gêné de dire, c'est que 90% de cette discussion est au-dessus de ma tête.

Il semble que 20 ans à gagner sa vie en écrivant des logiciels sans savoir ce qu'est le polymorphisme générique ou paramétrique, ne m'ont pas empêché de faire le travail.

Malheureusement, je n'ai pris le temps qu'il y a environ un an d'apprendre le go. J'ai fait la fausse hypothèse qu'il s'agissait d'une courbe d'apprentissage abrupte et qu'il faudrait trop de temps pour devenir productif.

Je n'aurais pas pu me tromper davantage.

J'ai pu apprendre suffisamment de Go pour créer un microservice qui a complètement détruit le service node.js avec lequel j'avais des problèmes de performances en moins d'un week-end.

Ironiquement, je ne faisais que jouer. Je n'étais pas particulièrement sérieux au sujet de conquérir le monde avec Go.

Et pourtant, en quelques heures, je me suis retrouvé assis de ma posture affaissée et vaincue, comme si j'étais sur le bord de mon siège en train de regarder un thriller d'action. L'API que je construisais s'est réunie si rapidement. J'ai réalisé que c'était en effet un langage dans lequel investir mon temps précieux, car il était évidemment si pragmatique dans sa conception.

Et c'est ce que j'aime chez Go. C'est très rapide..... Pour apprendre. Nous connaissons tous ici ses capacités de performance. Mais la vitesse à laquelle il peut être appris est inégalée par les 8 autres langues que j'ai apprises au fil des ans.

Depuis lors, j'ai chanté les louanges de Go et j'ai convaincu 4 autres développeurs d'en tomber amoureux. Je m'assois juste avec eux pendant quelques heures et je construis quelque chose. Les résultats parlent d'eux-mêmes.

Simplicité et rapidité d'apprentissage. Ce sont les véritables caractéristiques tueuses de la langue.

Les langages de programmation qui nécessitent des mois d'apprentissage intensif ne retiennent souvent pas les développeurs mêmes qu'ils cherchent à attirer. Nous avons du travail à faire et des employeurs qui veulent voir des progrès au quotidien (merci agile, appréciez-le)

Donc, il y a deux choses que j'espère que l'équipe Go pourra prendre en considération :

1) Quel problème quotidien cherchons-nous à résoudre ?

Je n'arrive pas à trouver un exemple concret, avec un bouchon de spectacle qui serait résolu par des génériques, ou quel que soit leur nom.

Exemples de style livre de recettes de tâches quotidiennes qui posent problème, avec un exemple de la façon dont elles pourraient être améliorées avec ces propositions de changement de langue.

2) Restez simple, comme toutes les autres fonctionnalités intéressantes de Go

Il y a des commentaires incroyablement intelligents ici. Mais je suis certain que la majorité des développeurs qui utilisent Go au quotidien pour la programmation générale, comme moi, sont parfaitement satisfaits et productifs avec les choses telles qu'elles sont.

Peut-être un argument du compilateur pour activer ces fonctionnalités avancées ? '--hardcore'

Je serais vraiment triste si nous avions un impact négatif sur les performances du compilateur. dis juste'n

Et c'est ce que j'aime chez Go. C'est très rapide..... Pour apprendre. Nous connaissons tous ici ses capacités de performance. Mais la vitesse à laquelle il peut être appris est inégalée par les 8 autres langues que j'ai apprises au fil des ans.

Je suis complètement d'accord. La combinaison de la puissance et de la simplicité dans un langage entièrement compilé est quelque chose de complètement unique. Je ne veux certainement pas que Go perde cela, et même si je veux des génériques, je ne pense pas qu'ils en valent la peine à ce prix. Je ne pense pas qu'il soit nécessaire de perdre cela, cependant.

Je n'arrive pas à trouver un exemple concret, avec un bouchon de spectacle qui serait résolu par des génériques, ou quel que soit leur nom.

J'ai deux principaux cas d'utilisation principaux pour les génériques : l'élimination passe-partout de type sécurisé des structures de données complexes, telles que les arbres binaires, les ensembles et sync.Map , et la possibilité d'écrire des fonctions de type sécurisé _compile-time_ qui fonctionnent sur la base uniquement sur la fonctionnalité de leurs arguments, plutôt que sur leur disposition en mémoire. Il y a des choses plus fantaisistes que je ne verrais pas d'inconvénient à pouvoir faire, mais cela ne me dérangerait pas de pouvoir les faire s'il est impossible d'ajouter un support pour elles sans casser complètement la simplicité du langage.

Pour être honnête, il existe déjà des fonctionnalités dans le langage qui sont assez abusables. Je pense que la principale raison pour laquelle ils ne sont _pas_ abusés est la culture Go de l'écriture de code "idiomatique", combinée à la bibliothèque standard fournissant des exemples propres et faciles à trouver d'un tel code, pour la plupart. Obtenir une bonne utilisation des génériques dans la bibliothèque standard devrait certainement être une priorité lors de leur mise en œuvre.

@camstuart

Je n'arrive pas à trouver un exemple concret, avec un bouchon de spectacle qui serait résolu par des génériques, ou quel que soit leur nom.

Les génériques vous évitent d'avoir à écrire le code vous-même. Ainsi, vous n'aurez plus jamais besoin d'implémenter vous-même une autre liste chaînée, un arbre binaire, un deque ou une file d'attente prioritaire. Vous n'aurez jamais besoin d'implémenter un algorithme de tri, un algorithme de partitionnement ou un algorithme de rotation, etc. Les structures de données deviennent des collections standard composant (une carte de listes par exemple), et le traitement devient des algorithmes standard composant et tourner). Si vous pouvez réutiliser ces composants, le taux d'erreur diminue, car chaque fois que vous réimplémentez une file d'attente prioritaire ou un algorithme de partitionnement, vous risquez de vous tromper et d'introduire un bogue.

Les génériques signifient que vous écrivez moins de code et que vous en réutilisez plus. Ils signifient que les fonctions de bibliothèque standard et bien entretenues et les types de données abstraits peuvent être utilisés dans plus de situations, vous n'avez donc pas à écrire les vôtres.

Mieux encore, tout cela peut techniquement être fait dans Go dès maintenant, mais seulement avec une perte presque complète de la sécurité des types au moment de la compilation _et_ avec une surcharge d'exécution potentiellement majeure. Les génériques vous permettent de le faire sans aucun de ces inconvénients.

Implémentation de la fonction générique :

/*

* "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
}

Appelant de fonction :

Sum(1, 1) // 2
// same as:
Sum(T{int}(1), T{int}(1)) // 2

Implémentation de la structure générique :

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

Votre interlocuteur:

list := NewList(ItemT{int})
list.Push(42)

En tant que personne apprenant Swift et ne l'aimant pas, mais avec beaucoup d'expérience dans d'autres langages comme Go, C, Java, etc. Je crois vraiment que les génériques (ou les modèles, ou peu importe comment vous voulez l'appeler) ne sont pas une bonne chose à ajouter au langage Go.

Peut-être que je suis juste plus expérimenté avec la version actuelle de Go, mais pour moi, cela ressemble à une régression vers C++ dans la mesure où il est plus difficile de comprendre le code que d'autres personnes ont écrit. L'espace réservé T classique pour les types rend si difficile la compréhension de ce qu'une fonction essaie de faire.

Je sais que c'est une demande de fonctionnalité populaire, donc je peux y faire face si elle atterrit, mais je voulais ajouter mes 2 cents (opinion).

@jlubawy
Connaissez-vous un autre moyen de ne jamais implémenter une liste chaînée ou un algorithme de tri rapide ? Comme le souligne Alexander Stepanov, la plupart des programmeurs ne peuvent pas définir correctement les fonctions "min" et "max", alors quel espoir avons-nous d'implémenter correctement des algorithmes plus complexes sans beaucoup de temps de débogage. Je préférerais de loin extraire les versions standard de ces algorithmes d'une bibliothèque et les appliquer uniquement aux types que j'ai. Quelle alternative existe-t-il ?

@jlubawy

ou modèle, ou comme vous voulez l'appeler

Tout dépend de la réalisation. si nous parlons de modèles C++, alors oui, ils sont difficiles à comprendre en général. Même les écrire est difficile. D'un autre côté, si nous prenons des génériques C #, c'est complètement autre chose. Le concept lui-même n'est pas un problème ici.

Si vous ne le saviez pas, la Go Team a annoncé un brouillon de Go 2.0 :
https://golang.org/s/go2designs

Il existe un brouillon de la conception des génériques dans Go 2.0 (contrat). Vous voudrez peut-être jeter un coup d'œil et donner votre avis sur leur Wiki .

Voici la section pertinente :

Génériques

• Aperçu
• Projet de conception
• Page de commentaires Wiki

Après avoir lu le brouillon, je demande :

Pourquoi

T : Ajoutable

signifie « un type T mettant en œuvre le contrat Addable » ? Pourquoi ajouter un nouveau
concept alors qu'on a déjà des INTERFACES pour ça ? L'affectation des interfaces est
vérifié au moment de la construction, nous avons donc déjà les moyens de ne pas avoir besoin de
concept supplémentaire ici. Nous pouvons utiliser ce terme pour dire quelque chose comme : Tout
type T implémentant l'interface Addable. De plus, T:_ ou T:Any
(être Any un mot-clé spécial ou un alias intégré d'interface{}) ferait l'affaire
l'astuce.

Juste je ne sais pas pourquoi réimplémenter la plupart des choses comme ça. Ne fait pas
sens et SERA redondant (car redondant est le nouveau traitement des erreurs par rapport
la gestion des paniques).

2018-09-14 6:15 GMT-05:00 Koala Yeung [email protected] :

Si vous ne le saviez pas, la Go Team a annoncé un brouillon de Go 2.0 :
https://golang.org/s/go2designs

Il existe un brouillon de la conception des génériques dans Go 2.0 (contrat). Vous voudrez peut-être
pour jeter un oeil et donner votre avis
https://github.com/golang/go/wiki/Go2GenericsFeedback sur leur Wiki
https://github.com/golang/go/wiki/Go2GenericsFeedback .

Voici la section pertinente :

Génériques

• Aperçu
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [Conception préliminaire] (https://go.googlesource.com/proposal/+/master/design/
  go2draft-contracts.md)
• Page de commentaires Wiki
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment-421326634 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
Ceci est un test pour les signatures de courrier à utiliser dans TripleMint

Edit : "[...] ferait l'affaire SI VOUS N'AVEZ BESOIN D'AUCUNE EXIGENCE PARTICULIÈRE SUR
L'ARGUMENT DE TYPE".

2018-09-17 11:10 GMT-05:00 Luis Masuelli [email protected] :

Après avoir lu le brouillon, je demande :

Pourquoi

T : Ajoutable

signifie « un type T mettant en œuvre le contrat Addable » ? Pourquoi ajouter un nouveau
concept alors qu'on a déjà des INTERFACES pour ça ? L'affectation des interfaces est
vérifié au moment de la construction, nous avons donc déjà les moyens de ne pas avoir besoin de
concept supplémentaire ici. Nous pouvons utiliser ce terme pour dire quelque chose comme : Tout
type T implémentant l'interface Addable. De plus, T:_ ou T:Any
(être Any un mot-clé spécial ou un alias intégré d'interface{}) ferait l'affaire
l'astuce.

Juste je ne sais pas pourquoi réimplémenter la plupart des choses comme ça. Ne fait pas
sens et SERA redondant (car redondant est le nouveau traitement des erreurs par rapport
la gestion des paniques).

2018-09-14 6:15 GMT-05:00 Koala Yeung [email protected] :

Si vous ne le saviez pas, la Go Team a annoncé un brouillon de Go 2.0 :
https://golang.org/s/go2designs

Il existe un brouillon de la conception des génériques dans Go 2.0 (contrat). Tu peux
je veux jeter un coup d'oeil et donner mon avis
https://github.com/golang/go/wiki/Go2GenericsFeedback sur leur Wiki
https://github.com/golang/go/wiki/Go2GenericsFeedback .

Voici la section pertinente :

Génériques

• Aperçu
  https://go.googlesource.com/proposal/+/master/design/go2draft-generics-overview.md
• [Brouillon de conception] (https://go.googlesource.com/p
  proposition/+/master/design/go2draft-contracts.md
  https://go.googlesource.com/proposal/+/master/design/go2draft-contracts.md
  )
• Page de commentaires Wiki
  https://github.com/golang/go/wiki/Go2GenericsFeedback

—
Vous recevez ceci parce que vous avez commenté.
Répondez directement à cet e-mail, consultez-le sur GitHub
https://github.com/golang/go/issues/15292#issuecomment-421326634 , ou muet
le fil
https://github.com/notifications/unsubscribe-auth/AlhWhS8xmN5Y85_aUKT5VnutoOKUAaLLks5ua4_agaJpZM4IG-xv
.

--
Ceci est un test pour les signatures de courrier à utiliser dans TripleMint

--
Ceci est un test pour les signatures de courrier à utiliser dans TripleMint

@luismasuelli-jobsity Si je lis correctement l'historique des implémentations génériques dans Go, il semble que la raison d'introduire les contrats soit parce qu'ils ne voulaient pas de surcharge d'opérateur dans les interfaces.

Une proposition antérieure qui a finalement été rejetée utilisait des interfaces pour contraindre le polymorphisme paramétrique, mais semble avoir été rejetée car vous ne pouviez pas utiliser d'opérateurs communs comme '+' dans de telles fonctions car il n'est pas définissable dans une interface. Les contrats vous permettent d'écrire t == t ou t + t afin que vous puissiez indiquer que le type doit prendre en charge l'égalité ou l'addition, etc.

Edit: De plus, Go ne prend pas en charge plusieurs interfaces de paramètres de type, donc d'une certaine manière, Go a séparé la classe de types en deux choses distinctes, les contrats qui relient les paramètres de type des fonctions les uns aux autres et les interfaces qui fournissent des méthodes. Ce qu'il perd, c'est la possibilité de sélectionner une implémentation de classe de types basée sur plusieurs types. C'est sans doute plus simple si vous n'avez besoin d'utiliser que des interfaces ou des contrats, mais plus complexe si vous devez utiliser les deux ensemble.

Pourquoi T:Addable signifie « un type T mettant en œuvre le contrat Addable » ?

Ce n'est en fait pas ce que cela signifie; il ressemble juste à cela pour un argument de type. Ailleurs dans le brouillon, il est fait le commentaire que vous ne pouvez avoir qu'un seul contrat par fonction, et c'est là que la principale différence entre en jeu. Les contrats sont en fait des déclarations sur les types de fonction, pas seulement les types indépendamment. Par exemple, si vous avez

func Example(type K, V someContract)(k K, v V) V

vous pouvez faire quelque chose comme

contract someContract(k K, v V) {
  k.someMethod(v)
}

Cela simplifie considérablement la coordination de plusieurs types sans avoir à spécifier de manière redondante les types dans la signature de la fonction. N'oubliez pas qu'ils essaient d'éviter le "modèle générique qui se répète curieusement". Par exemple, la même fonction avec des interfaces paramétrées utilisées pour contraindre les types serait quelque chose comme

type someMethoder(V) interface {
  someMethod(V)
}

func Example(type K: someMethoder(V), V)(k K, v V) V

C'est un peu gênant. La syntaxe du contrat vous permet de le faire si vous en avez besoin, car les "arguments" du contrat sont remplis automatiquement par le compilateur si le contrat en a le même nombre que les paramètres de type de la fonction. Vous pouvez cependant les spécifier manuellement si vous le souhaitez, ce qui signifie que vous _pourriez_ faire func Example(type K, V someContract(K, V))(k K, v V) V si vous le vouliez vraiment, bien que ce ne soit pas particulièrement utile dans cette situation.

Une façon de préciser que les contrats concernent des fonctions entières, et non des arguments individuels, serait de simplement les associer en fonction de leur nom. Par example,

contract Example(k K, v V) {
  k.someMethod(v)
}

func Example(type K, V)(k K, v V) V

serait le même que ci-dessus. L'inconvénient, cependant, est que les contrats ne seraient pas réutilisables et vous perdriez cette possibilité de spécifier manuellement les arguments du contrat.

Edit : Pour montrer davantage pourquoi ils veulent résoudre le motif curieusement répétitif, considérons le problème du chemin le plus court auquel ils se référaient sans cesse. Avec des interfaces paramétrées, la définition finit par ressembler à

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

Personnellement, j'aime plutôt la façon dont les contrats sont spécifiés pour les fonctions. Je ne suis pas _ trop _ désireux d'avoir simplement des corps de fonction "normaux" comme spécification de contrat réelle, mais je pense que beaucoup de problèmes potentiels pourraient être résolus en introduisant une sorte de simplificateur de type gofmt qui simplifie automatiquement les contrats pour vous, supprimant parties étrangères. Ensuite, vous _pourriez_ simplement y copier le corps d'une fonction, le simplifier et le modifier à partir de là. Je ne sais pas comment cela sera possible à mettre en œuvre, cependant, malheureusement.

Cependant, certaines choses seront encore un peu difficiles à spécifier, et le chevauchement apparent entre les contrats et les interfaces semble toujours un peu étrange.

Je trouve la version "CRTP" beaucoup plus claire, plus explicite et plus facile à travailler (pas besoin de créer des contrats qui n'existent que pour définir la relation entre des contrats préexistants sur un ensemble de variables). Certes, cela pourrait simplement être les nombreuses années de familiarité avec l'idée.

Précisions. Par la conception préliminaire , le contrat peut être appliqué à la fois aux fonctions et aux types .

"""
C'est sans doute plus simple si vous n'avez besoin d'utiliser que des interfaces ou des contrats, mais plus complexe si vous devez utiliser les deux ensemble.
"""

Tant qu'ils vous permettent, à l'intérieur d'un contrat, de référencer une ou plusieurs interfaces (au lieu de seulement des opérateurs et des fonctions, permettant ainsi DRY), ce problème (et ma réclamation) sera résolu. Il y a une chance que j'aie mal lu ou que je n'aie pas complètement lu les contrats, et aussi une chance que ladite fonctionnalité soit prise en charge et que je ne l'aie pas remarqué. Si ce n'est pas le cas, ça devrait l'être.

Ne pouvez-vous pas faire ce qui suit ?

contract Example(t T, v V) {
  t.(interface{
    SomeMethod() V
  })
}

Vous ne pouvez pas utiliser une interface déclarée ailleurs en raison de la restriction selon laquelle vous ne pouvez pas référencer les identifiants du même package dans lequel le contrat est déclaré, mais vous pouvez le faire. Ou ils pourraient simplement supprimer cette restriction; cela semble un peu arbitraire.

@DeedleFake Non, car tout type d'interface peut être affirmé par type (et ensuite potentiellement paniquer au moment de l'exécution, mais les contrats ne sont pas exécutés). Mais vous pouvez utiliser une affectation à la place.