14 — Generics

// ┌──────────────────────────┬──────────────────────────────────────────┐
// │ Use generics for          │ Avoid generics for                       │
// │ ──────────────────────────│ ───────────────────────────────────────── │
// │ Container types (Stack[T])│ Single-use code (write it concretely)    │
// │ Utility funcs (Map, Filter)│ When an interface is clearer             │
// │ Algorithms over types     │ Over-abstraction (a generic framework)   │
// │ Replacing interface{} +   │ When the type constraint is so specific   │
// │   type assertions          │   that only one type ever satisfies it    │
// └──────────────────────────┴──────────────────────────────────────────┘

// ❌ ANTI-PATTERN: over-genericizing single-use code
//   func process[T any](items []T, fn func(T) T) []T { ... }
//   If you only call this with []User once, just write:
//   func processUsers(items []User, fn func(User) User) []User { ... }

// ✅ CORRECT: generics for reusable containers:
//   Stack[T], Set[T], Queue[T], Map[K, V] — used across many types

// ❌ ANTI-PATTERN: generic with a single-type constraint
//   func OnlyInt[T int](v T) T { return v }
//   If only int works, just use int — generics add no value.

💡 Tips & Tricks

• Idiom: prefer slices/maps (Go 1.21+) over hand-rolled generic helpers — they cover Sort, Contains, Clone, BinarySearch, Keys, Values, Equal. Reach for your own generics only when the stdlib doesn't cover the case.
• Idiom: use ~T in constraints to include named types — ~int matches int AND type MyInt int. Without ~, named types based on int don't match, which is rarely what you want for numeric constraints.
• Idiom: use cmp.Ordered (Go 1.21+) for "any orderable type" — covers integers, floats, and strings. Pre-1.21, define the constraint yourself or use golang.org/x/exp/constraints.
• Idiom: don't over-genericize — if a function is used with one type, write it concretely. Generics shine for reusable containers and algorithms; over-abstracting single-use code adds complexity.
• Idiom: use generics to replace interface{} + type assertions where the type is known at the call site — a Stack[T] is type-safe (no any, no assertion), and the compiler catches type mismatches at compile time.
• Performance: generic functions are monomorphized in most cases — the compiler generates a version per type argument, so there's no runtime overhead (no virtual dispatch like interfaces). But this increases binary size.

⚠️ Edge Cases & Gotchas

• Generics don't work with methods: Go doesn't support generic methods (methods with their own type parameters distinct from the receiver's). Methods can use the receiver's type parameters, but can't add new ones. This is a known limitation.
• comparable doesn't include slices/maps/functions: a struct containing a slice isn't comparable, even if all other fields are. Can't use it as a map key or in == within a generic function.
• ~T requires the underlying type: ~int matches type MyInt int but NOT type MyStruct struct{ x int }. The ~ matches underlying type, not struct fields.
• Type inference can fail on nil: Map(nil, fn) — can't infer T from a nil slice. Specify explicitly: Map[int, int](nil, fn).
• Generic types can't have generic methods: type Stack[T any] struct{}; func (s *Stack[T]) Map[U any](fn func(T) U) []U — compile error. This is the #1 generics limitation.
• Constraint interfaces with methods can't be used as regular interfaces: type Stringer interface { String() string } works as both a constraint and a regular interface. But type Num interface { ~int | ~float64; String() string } can only be a constraint (type sets can't be in regular interfaces).
• Binary size: generics are monomorphized — each type argument generates a separate copy. For a generic function used with 10 types, the binary includes 10 copies. Usually negligible, but can matter for embedded/binary-size-constrained builds.
• Zero value of a type parameter: var zero T gives the zero value of T — works for any T. Can't do T{} (struct literal) unless T is constrained to structs.

🧠 Quick Quiz

type MyInt int

func Add[T ~int](a, b T) T { return a + b }

func main() {
    var x MyInt = 10
    var y MyInt = 20
    fmt.Println(Add(x, y))
}