Use when deciding whether to use Go generics, writing generic functions or types, choosing constraints, or picking between type aliases and type definitions. Also use when a user is writing a utility function that could work with multiple types, even if they don't mention generics explicitly. Does n

Go Generics and Type Parameters Compatibility: Generics require Go 1.18+. Resource Routing references/CONSTRAINTS.md Read when composing constraints, using type sets, or choosing between generics and interfaces. When to Use Generics Start with concrete types. Generalize only when a second type appears. Prefer Generics When Multiple types share identical logic (sorting, filtering, map/reduce) You would otherwise rely on any and excessive type switching You are building a reusable data structure (concurrent safe set, ordered map) Avoid Generics When Only one type is being instantiated in practice Interfaces already model the shared behavior cleanly The generic code is harder to read than the type specific alternative "Write code, don't design types." — Robert Griesemer and Ian Lance Taylor Decision Flow Bad: Good: Type Parameter Naming Name Typical Use T General type parameter K Map key type V Map value type E Element/item type For complex constraints, a short descriptive name is acceptable: Type Aliases vs Type Definitions Type aliases ( type Old = new.Name ) are rare — use only for package migration or gradual API refactoring. Constraint Composition Combine constraints with ~ (underlying type) and (union): Use the constraints package or cmp package (Go 1.21+) for standard constraints like cmp.Ordered instead of writing your own. Common Pitfalls Don't Wrap Standard Library Types Generics justify their complexity when they eliminate duplication across multiple call sites . A single use generic is just indirection. Don't Use Generics for Interface Satisfaction Avoid Over Constraining Quick Reference Topic Guidance When to use generics Only when multiple types share identical logic and interfaces don't suffice Starting point Write concrete code first; generalize later Naming Single uppercase letter ( T , K , V , E ) Type aliases Same type, alternate name; use only for migration Constraint composition Use ~ for underlying types, for unions; prefer cmp.Ordered over custom Common pitfall Don't genericize single use code or when interfaces suffice Related Skills Interfaces vs generics : See [go interfaces](../go interfaces/SKILL.md) when deciding whether an interface already models the shared behavior without generics Type declarations : See [go declarations](../go declarations/SKILL.md) when defining new types, type aliases, or choosing between type definitions and aliases Documenting generic APIs : See [go documentation](../go documentation/SKILL.md) when writing doc comments and runnable examples for generic functions Naming type parameters : See [go naming](../go naming/SKILL.md) when choosing names for type parameters or constraint interfaces

go-generics