Generics: type parameters and constraints

The problem

Before Go 1.18, if you wanted a function that finds the biggest item in a slice, you wrote MaxInts, MaxFloats and MaxStrings, all identical except the type. Or you used any and type assertions, losing type safety. Generics solve this: write the logic once, and the compiler checks it for every type you use.

A generic function

import "cmp"

func Max[T cmp.Ordered](a, b T) T {
	if a > b {
		return a
	}
	return b
}

func main() {
	fmt.Println(Max(3, 7))            // 7
	fmt.Println(Max(2.5, 1.5))        // 2.5
	fmt.Println(Max("chai", "coffee")) // coffee
}

• Type parameter: a placeholder type name in square brackets, like [T any].
• Constraint: an interface that says what T must support. Here, ordering with < and >.
• Type inference: Go usually works out T from the arguments, so you write Max(3, 7), not Max[int](3, 7).
• Instantiation: you can also give the type explicitly: Max[float64](3, 2.5).

Common constraints

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

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

type Paise int64

func main() {
	fmt.Println(Sum([]int{1, 2, 3}))          // 6
	fmt.Println(Sum([]float64{1.5, 2.25}))    // 3.75
	fmt.Println(Sum([]Paise{1000, 2550}))      // 3550 (works because of ~int64)
}

Generic types

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, bool) {
	var zero T
	if len(s.items) == 0 {
		return zero, false
	}
	v := s.items[len(s.items)-1]
	s.items = s.items[:len(s.items)-1]
	return v, true
}

func main() {
	var undo Stack[string]
	undo.Push("type A")
	undo.Push("type B")
	v, _ := undo.Pop()
	fmt.Println(v) // type B
}

Generics you already get for free

The standard library's slices and maps packages (Go 1.21+) are generic: slices.Sort, slices.Contains, slices.Index, maps.Keys and friends work for any suitable type. The built-in min and max, and the cmp package, use the same ideas. Often you will USE generics far more than you write them.

When not to use generics

• If the code only ever handles one type, write it for that type.
• If what differs between types is BEHAVIOUR (each type does it its own way), use an interface with methods, not a type parameter.
• Do not turn every function generic "to be flexible". It makes code harder to read and errors harder to understand.
• A good test: you are about to copy-paste a function and only change the types. That is when generics help.