Avertissement: je ne joue avec Go que depuis un jour maintenant, il y a donc de fortes chances que j'aie raté beaucoup de choses.

Est-ce que quelqu'un sait pourquoi il n'y a pas de support réel pour les génériques / templates / whatsInAName dans Go? Il existe donc un générique map, mais qui est fourni par le compilateur, tandis qu'un programmeur Go ne peut pas écrire sa propre implémentation. Avec tous les discours sur le fait de rendre Go aussi orthogonal que possible, pourquoi puis-je UTILISER un type générique sans en CRÉER un nouveau?

Surtout en ce qui concerne la programmation fonctionnelle, il y a des lambdas, même des fermetures, mais avec un système de type statique manquant de génériques, comment écrire des fonctions génériques d'ordre supérieur comme filter(predicate, list)? OK, les listes liées et autres peuvent être faites en interface{}sacrifiant la sécurité du type.

Comme une recherche rapide sur SO / Google n'a révélé aucune idée, il semble que des génériques, voire pas du tout, seront ajoutés à Go après coup. Je fais confiance à Thompson pour faire bien mieux que les gars de Java, mais pourquoi garder les génériques à l'écart? Ou sont-ils planifiés et ne sont tout simplement pas encore mis en œuvre?

cette réponse vous trouverez ici: http://golang.org/doc/faq#generics

Pourquoi Go n'a-t-il pas de types génériques?

Des génériques peuvent bien être ajoutés à un moment donné. Nous ne ressentons pas une urgence pour eux, même si nous comprenons que certains programmeurs le font.

Les génériques sont pratiques mais ils ont un coût en complexité dans le système de type et le temps d'exécution. Nous n'avons pas encore trouvé de design qui donne une valeur proportionnée à la complexité, même si nous continuons à y réfléchir. Pendant ce temps, les cartes et les tranches intégrées de Go, ainsi que la possibilité d'utiliser l'interface vide pour construire des conteneurs (avec unboxing explicite) signifient dans de nombreux cas qu'il est possible d'écrire du code qui fait ce que les génériques permettraient, bien que moins facilement.

Cela reste une question ouverte.

Aller 2

Il existe un projet de conception pour les génériques sur https://blog.golang.org/go2draft .

Aller 1

Russ Cox, l'un des vétérans du Go, a écrit un article de blog intitulé The Generic Dilemma , dans lequel il demande

… Voulez-vous des programmeurs lents, des compilateurs lents et des binaires gonflés, ou des temps d'exécution lents?

Les programmeurs lents étant le résultat de l'absence de génériques, les compilateurs lents sont causés par des génériques comme C ++ et les temps d'exécution lents découlent de l'approche boxing-unboxing utilisée par Java.

La quatrième possibilité non mentionnée dans le blog est la voie C #. Générer le code spécialisé comme en C ++, mais au moment de l'exécution quand cela est nécessaire. Je l'aime vraiment, mais Go est très différent de C # donc ce n'est probablement pas du tout applicable ...

Je devrais mentionner que l'utilisation de la technique de programmation générique populaire Java 1.4 en go qui interface{}souffre des mêmes problèmes que le boxing-unboxing (car c'est ce que nous faisons), en plus de la perte de sécurité du type de compilation. Pour les petits types (comme les ints), Go optimise le interface{}type de sorte qu'une liste d'entiers qui ont été transtypés en interface {} occupe une zone contiguë de la mémoire et ne prend que deux fois plus d'espace que les entiers normaux. Cependant, il y a toujours la surcharge des vérifications d'exécution lors de la diffusion depuis interface{}. Référence .

Tous les projets qui ajoutent un support générique pour aller (il y en a plusieurs et tous sont intéressants) suivent uniformément la voie C ++ de la génération de code temporel de compilation.

Même si les génériques ne sont pas actuellement intégrés, il existe plusieurs implémentations externes de génériques pour go, qui utilisent des commentaires en combinaison avec de petits utilitaires qui génèrent du code.

Voici une telle implémentation: http://clipperhouse.github.io/gen/

En fait, selon ce post:

De nombreuses personnes ont conclu (à tort) que la position de l'équipe de Go est «Go n'aura jamais de génériques». Au contraire, nous comprenons le potentiel des génériques, à la fois pour rendre Go beaucoup plus flexible et puissant et pour rendre Go beaucoup plus compliqué. Si nous devons ajouter des génériques, nous voulons le faire d'une manière qui offre autant de flexibilité et de puissance avec le moins de complexité supplémentaire possible.

Le polymorphisme paramétrique (génériques) est à l'étude pour Go 2 .

Cette approche introduirait le concept de contrat , qui peut être utilisé pour exprimer des contraintes sur les paramètres de type:

contract Addable(a T) {
  a + a // Could be += also
}

Un tel contrat pourrait alors être utilisé ainsi:

func Sum(type T Addable)(l []T) (total T) {
  for _, e := range l {
    total += e
  }
  return total
}

C'est une proposition à ce stade.

Votre filter(predicate, list)fonction pourrait être implémentée avec un paramètre de type comme celui-ci:

func Filter(type T)(f func(T) bool, l []T) (result []T) {
  for _, e := range l {
    if f(e) {
      result = append(result, e)
    }
  }
  return result
}

Dans ce cas, il n'est pas nécessaire de contraindre T.