Génériques en Golang : paramètres de type, contraintes et exemples

Une fonction générique

Les paramètres de type se placent entre crochets avant les paramètres ordinaires. Chacun a une contrainte qui indique les types autorisés.

package main

import (
	"fmt"
	"strconv"
)

func Map[T, U any](items []T, f func(T) U) []U {
	out := make([]U, 0, len(items))
	for _, it := range items {
		out = append(out, f(it))
	}
	return out
}

func main() {
	nums := []int{1, 2, 3}

	squares := Map(nums, func(n int) int { return n * n })
	fmt.Println(squares)

	labels := Map(nums, strconv.Itoa)
	fmt.Printf("%q\n", labels)

	lengths := Map([]string{"go", "rust", "c"}, func(s string) int { return len(s) })
	fmt.Println(lengths)
}

T et U sont déduits des arguments, donc vous écrivez rarement Map[int, string](...). L'inférence part des arguments de la fonction ; elle ne peut pas déduire un type qui n'apparaît que dans le résultat. Pour func Zero[T any]() T, vous devez écrire Zero[int]().

Avant Go 1.18, cette fonction devait être écrite une fois par type, ou prendre un []interface{} et perdre la sécurité du typage.

Contraintes

Une contrainte est une interface. Elle limite les types utilisables et, en échange, indique au compilateur quelles opérations sont permises sur les valeurs de ce type.

package main

import (
	"cmp"
	"fmt"
)

func Index[T comparable](s []T, target T) int {
	for i, v := range s {
		if v == target { // needs comparable
			return i
		}
	}
	return -1
}

func Largest[T cmp.Ordered](s []T) T {
	m := s[0]
	for _, v := range s[1:] {
		if v > m { // needs cmp.Ordered
			m = v
		}
	}
	return m
}

func main() {
	fmt.Println(Index([]string{"a", "b", "c"}, "c"))
	fmt.Println(Largest([]float64{2.5, 9.1, 4.0}))
	fmt.Println(Largest([]string{"pear", "apple", "zucchini"}))
}

Avec any au lieu de comparable, v == target ne compile pas : invalid operation: v == target (incomparable types in type set). C'est la contrainte qui rend l'opérateur légal.

Ces deux fonctions existent déjà : slices.Index et slices.Max. Les packages standard slices, maps et cmp couvrent la plupart des besoins génériques du quotidien, donc regardez-les avant d'écrire les vôtres.

Contraintes personnalisées avec des unions de types et ~

Une contrainte peut lister des types avec |. Les opérateurs autorisés sont ceux que tous les types listés supportent.

package main

import "fmt"

type Number interface {
	~int | ~int64 | ~float64
}

func Sum[T Number](nums []T) T {
	var total T
	for _, n := range nums {
		total += n
	}
	return total
}

type Cents int64

func main() {
	fmt.Println(Sum([]int{1, 2, 3}))
	fmt.Println(Sum([]float64{0.5, 0.25}))
	fmt.Println(Sum([]Cents{199, 250})) // works because of ~int64
}

Le tilde compte. ~int64 signifie « tout type dont le type sous-jacent est int64 », donc le type nommé Cents est accepté. Écrit simplement int64, Sum([]Cents{...}) échoue avec Cents does not satisfy Number (possibly missing ~ for int64 in Number).

Les interfaces contenant des unions de types ne peuvent servir que de contraintes, jamais de types de variables ordinaires. var n Number ne compile pas.

Le package golang.org/x/exp/constraints propose des contraintes toutes prêtes Integer, Float et Signed. Il est hors de la bibliothèque standard, donc l'environnement d'exécution d'ici ne peut pas l'importer ; cmp.Ordered est la contrainte standard.

Types génériques

Les structs, slices, maps et autres types peuvent aussi avoir des paramètres de type. Les méthodes d'un type générique utilisent les paramètres du receveur.

package main

import (
	"errors"
	"fmt"
)

type Stack[T any] struct {
	items []T
}

func (s *Stack[T]) Push(v T) {
	s.items = append(s.items, v)
}

func (s *Stack[T]) Pop() (T, error) {
	var zero T
	if len(s.items) == 0 {
		return zero, errors.New("empty stack")
	}
	v := s.items[len(s.items)-1]
	s.items = s.items[:len(s.items)-1]
	return v, nil
}

func (s *Stack[T]) Len() int { return len(s.items) }

type Pair[K comparable, V any] struct {
	Key K
	Val V
}

func main() {
	var s Stack[string]
	s.Push("a")
	s.Push("b")
	v, _ := s.Pop()
	fmt.Println(v, s.Len())

	_, err := (&Stack[int]{}).Pop()
	fmt.Println(err)

	p := Pair[string, int]{Key: "age", Val: 31}
	fmt.Printf("%+v\n", p)
}

Deux détails de cet exemple reviennent constamment :

• La valeur zéro de T. var zero T est la façon de renvoyer « rien » depuis du code générique. Il n'existe pas de T{} ni de nil qui fonctionne pour tous les types.
• L'instanciation. Un type générique doit être instancié avant usage : Stack[string], pas Stack. Dans ses propres méthodes, le receveur s'écrit Stack[T].

Go 1.24 a ajouté les alias de types génériques : type Set[T comparable] = map[T]struct{} compile désormais.

Les limites que vous rencontrerez

• Pas de paramètres de type sur les méthodes. func (s *Stack[T]) Map[U any](...) n'est pas permis. Utilisez une fonction de haut niveau.
• Pas de spécialisation. Vous ne pouvez pas écrire une implémentation séparée pour T = string. Un type switch sur any(v) dans la fonction est le contournement, et en général le signe que les génériques ne sont pas le bon outil.
• Pas de contrainte d'opérateur par nom. Vous ne pouvez pas dire « tout type qui a une méthode + » ; vous listez les types dans une union.
• L'accès aux champs via une contrainte ne fonctionne pas. Même si chaque type d'une union a un champ ID, v.ID n'est pas permis. Mettez plutôt une méthode dans la contrainte.

Quand ne pas utiliser les génériques

Les génériques conviennent aux types conteneurs (piles, ensembles, caches, arbres) et aux algorithmes sur des slices et des maps qui font la même chose quel que soit le type des éléments. Ils ne conviennent pas partout.

• Un seul type concret. Si la fonction n'est jamais appelée qu'avec des []User, une version générique ajoute un coût de lecture et rien d'autre.
• Un comportement qui dépend du type. C'est le rôle des interfaces. Une fonction qui prend un io.Writer est plus simple qu'une fonction qui prend [T io.Writer], et fonctionne pareil.
• Remplacer des paramètres interface. func Print[T fmt.Stringer](v T) n'apporte rien par rapport à func Print(v fmt.Stringer).

La recommandation de l'équipe Go elle-même : écrivez d'abord le code pour un type précis, et passez aux paramètres de type quand vous vous surprenez à écrire le même code une deuxième fois avec seulement les types qui changent.

Erreurs courantes

• Utiliser any là où comparable ou cmp.Ordered est nécessaire. Le compilateur rejette == ou < sur un paramètre de type any.
• Oublier ~. Les types définis par l'utilisateur comme type ID int ne satisfont pas une contrainte int simple.
• Renvoyer nil pour un paramètre de type. Ce n'est pas permis, sauf si la contrainte limite T à des types de type pointeur. Renvoyez une valeur zéro.
• Écrire une fonction générique qui existe déjà. Regardez d'abord slices, maps et cmp.