From golang-skills
Guides Go developers on using generics: when to use over interfaces/concretes, writing functions/types, constraint composition, type parameter naming, aliases vs definitions.
npx claudepluginhub cxuu/golang-skills --plugin golang-skillsThis skill uses the workspace's default tool permissions.
---
Guides Go interface design patterns: consumer-side definition, accept-interfaces-return-structs, composition, implicit satisfaction, and pitfalls. For decoupling packages, defining contracts, reviewing usage, refactoring for testability.
Guides Go struct and interface design: composition, embedding, type assertions/switches, segregation, dependency injection, field tags, pointer/value receivers. Use for type design and interface implementation.
Designs, reviews, and audits Go interfaces using discovery-over-design principles. Flags oversized interfaces, wrong definition sites, premature abstractions, and usage smells.
Share bugs, ideas, or general feedback.
Start with concrete types. Generalize only when a second type appears.
any and excessive type switching"Write code, don't design types." — Robert Griesemer and Ian Lance Taylor
Do multiple types share identical logic?
├─ No → Use concrete types
├─ Yes → Do they share a useful interface?
│ ├─ Yes → Use an interface
│ └─ No → Use generics
Bad:
// Premature generics: only ever called with int
func Sum[T constraints.Integer | constraints.Float](vals []T) T {
var total T
for _, v := range vals {
total += v
}
return total
}
Good:
func SumInts(vals []int) int {
var total int
for _, v := range vals {
total += v
}
return total
}
| 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:
func Marshal[Opts encoding.MarshalOptions](v any, opts Opts) ([]byte, error)
Type aliases (type Old = new.Name) are rare — use only for package migration
or gradual API refactoring.
Combine constraints with ~ (underlying type) and | (union):
type Numeric interface {
~int | ~int8 | ~int16 | ~int32 | ~int64 |
~float32 | ~float64
}
func Sum[T Numeric](vals []T) T {
var total T
for _, v := range vals {
total += v
}
return total
}
Use the constraints package or cmp package (Go 1.21+) for standard constraints
like cmp.Ordered instead of writing your own.
Read references/CONSTRAINTS.md when writing custom type constraints, composing constraints with ~ and |, or debugging type inference issues.
// Bad: generic wrapper adds complexity without value
type Set[T comparable] struct {
m map[T]struct{}
}
// Better: use map[T]struct{} directly when the usage is simple
seen := map[string]struct{}{}
Generics justify their complexity when they eliminate duplication across multiple call sites. A single-use generic is just indirection.
// Bad: T is only used to satisfy an interface — just use the interface
func Process[T io.Reader](r T) error { ... }
// Good: accept the interface directly
func Process(r io.Reader) error { ... }
// Bad: constraint is more restrictive than needed
func Contains[T interface{ ~int | ~string }](slice []T, target T) bool { ... }
// Good: comparable is sufficient
func Contains[T comparable](slice []T, target T) bool { ... }
| 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, ` |
| Common pitfall | Don't genericize single-use code or when interfaces suffice |