Golang Generics: Typparameter, Constraints und Beispiele

Eine generische Funktion

Typparameter stehen in eckigen Klammern vor den normalen Parametern. Jeder hat ein Constraint, das festlegt, welche Typen erlaubt sind.

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 und U werden aus den Argumenten abgeleitet, also schreibst du selten Map[int, string](...). Die Inferenz arbeitet mit den Funktionsargumenten; einen Typ, der nur im Ergebnis vorkommt, kann sie nicht ableiten. Bei func Zero[T any]() T musst du Zero[int]() schreiben.

Vor Go 1.18 musste diese Funktion für jeden Typ einzeln geschrieben werden oder []interface{} nehmen und die Typsicherheit verlieren.

Constraints

Ein Constraint ist ein Interface. Es begrenzt, welche Typen verwendet werden können, und sagt dem Compiler im Gegenzug, welche Operationen auf Werten dieses Typs erlaubt sind.

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

Mit any statt comparable kompiliert v == target nicht: invalid operation: v == target (incomparable types in type set). Erst das Constraint macht den Operator erlaubt.

Diese beiden Helfer gibt es schon: slices.Index und slices.Max. Die Standardpakete slices, maps und cmp decken den meisten generischen Alltagsbedarf ab, also schau dort nach, bevor du deine eigenen schreibst.

Eigene Constraints mit Typ-Unions und ~

Ein Constraint kann Typen mit | auflisten. Erlaubt sind die Operatoren, die jeder aufgelistete Typ unterstützt.

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
}

Die Tilde zählt. ~int64 bedeutet „jeder Typ, dessen zugrunde liegender Typ int64 ist“, also wird der benannte Typ Cents akzeptiert. Mit einem schlichten int64 scheitert Sum([]Cents{...}) mit Cents does not satisfy Number (possibly missing ~ for int64 in Number).

Interfaces mit Typ-Unions können nur als Constraints verwendet werden, nie als gewöhnliche Variablentypen. var n Number kompiliert nicht.

Das Paket golang.org/x/exp/constraints bietet fertige Constraints wie Integer, Float und Signed. Es liegt außerhalb der Standardbibliothek, also kann der Runner hier es nicht importieren; cmp.Ordered ist das Standard-Constraint.

Generische Typen

Auch Structs, Slices, Maps und andere Typen können Typparameter haben. Methoden auf einem generischen Typ verwenden die Parameter des Receivers.

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

Zwei Details aus diesem Beispiel tauchen ständig auf:

• Der Nullwert von T. Mit var zero T gibst du in generischem Code „nichts“ zurück. Ein T{} oder nil, das für jeden Typ funktioniert, gibt es nicht.
• Instanziierung. Ein generischer Typ muss vor der Verwendung instanziiert werden: Stack[string], nicht Stack. In seinen eigenen Methoden schreibst du den Receiver als Stack[T].

Go 1.24 hat generische Typ-Aliase eingeführt: type Set[T comparable] = map[T]struct{} kompiliert jetzt.

Grenzen, auf die du stoßen wirst

• Keine Typparameter an Methoden. func (s *Stack[T]) Map[U any](...) ist nicht erlaubt. Nimm eine Funktion auf oberster Ebene.
• Keine Spezialisierung. Du kannst keine eigene Implementierung für T = string schreiben. Ein Type Switch auf any(v) in der Funktion ist der Workaround und meist ein Hinweis, dass Generics das falsche Werkzeug sind.
• Keine Operator-Constraints per Name. Du kannst nicht „jeder Typ mit einer +-Methode“ sagen; du listest die Typen in einer Union auf.
• Feldzugriff über ein Constraint funktioniert nicht. Selbst wenn jeder Typ in einer Union ein Feld ID hat, ist v.ID nicht erlaubt. Nimm stattdessen eine Methode ins Constraint.

Wann du keine Generics nutzen solltest

Generics passen zu Container-Typen (Stacks, Sets, Caches, Bäume) und zu Algorithmen über Slices und Maps, die für jeden Elementtyp dasselbe tun. Sie passen nicht überall.

• Ein einziger konkreter Typ. Wird die Funktion immer nur mit []User aufgerufen, kostet eine generische Version Lesezeit und bringt sonst nichts.
• Verhalten, das sich je nach Typ unterscheidet. Dafür gibt es Interfaces. Eine Funktion, die einen io.Writer nimmt, ist einfacher als eine mit [T io.Writer] und funktioniert genauso.
• Interface-Parameter ersetzen. func Print[T fmt.Stringer](v T) ist nicht besser als func Print(v fmt.Stringer).

Die Richtlinie des Go-Teams selbst: Schreib den Code zuerst für einen bestimmten Typ und greif zu Typparametern, wenn du merkst, dass du denselben Code ein zweites Mal schreibst und sich nur die Typen ändern.

Häufige Fehler

• any verwenden, wo comparable oder cmp.Ordered nötig ist. Der Compiler lehnt == oder < auf einem Typparameter mit any ab.
• Das ~ vergessen. Selbst definierte Typen wie type ID int erfüllen ein schlichtes int-Constraint nicht.
• nil für einen Typparameter zurückgeben. Nicht erlaubt, außer das Constraint beschränkt T auf pointerartige Typen. Gib einen Nullwert zurück.
• Einen generischen Helfer schreiben, den es schon gibt. Schau zuerst in slices, maps und cmp.