Why must a Go generic type such as Stack[T] always be written with explicit type arguments?

## Two different things get type arguments Go's generics attach type parameters to two kinds of declaration: ```go func Map[T, U any](s []T, f func(T) U) []U // generic function type Stack[T any] struct{ items []T } // generic type ``` Both must be *instantiated* before they mean anything concrete. The asymmetry candidates trip on is that only one of them gets inference: **generic functions do, generic types never do.** ## Why the rule is what it is Inference works by unification against the types of the values passed at a call. A call is the event that provides evidence: ```go Map(nums, strconv.Itoa) // []int vs []T gives T = int ``` Writing `Stack[int]` is not a call. It is a *type expression* — it appears where a type is expected: in `var s Stack[int]`, in a struct field, in a parameter list, in a return type, in `make(chan Stack[int])`, in a composite literal `Stack[int]{}`, and in the receiver of a method (`func (s *Stack[T]) Push(v T)`, where `T` is the receiver's declared type parameter, not an inferred one). None of those positions carries values whose types could be matched. With no evidence, there is no inference, and the language does not guess — `var s Stack` is a compile error saying the generic type needs type arguments. This is not an oversight. Inferring type arguments for generic types has been discussed repeatedly and remains unimplemented; assume you must write them. ## The consequence for API design: constructors Since a generic type never infers, the ergonomics of your package come from the *functions* around it. Compare three shapes: ```go type Stack[T any] struct { items []T } // 1. Zero value: always explicit at the declaration site. var a Stack[int] // 2. Constructor with no arguments: T appears only in the result, // so this infers nothing either. func NewStack[T any]() *Stack[T] { return &Stack[T]{} } b := NewStack[int]() // 3. Constructor that takes values: T is reachable, so it infers. func StackOf[T any](items ...T) *Stack[T] { return &Stack[T]{items: items} } c := StackOf(1, 2, 3) // *Stack[int] ``` Shape 3 is why `slices` and `maps` helpers read so cleanly: their type parameters always appear in a parameter. If you are writing a container other teams will use, ask whether the common construction path passes any values at all. If it does, take them and let inference do the work. If it genuinely does not, accept `NewStack[int]()` rather than inventing a dummy parameter — a fake argument to please inference is worse than an honest type argument. ## Shortening repeated instantiations When one instantiation dominates a package, an alias removes the repetition without hiding anything: ```go type IntStack = Stack[int] ``` Aliases to an already-instantiated generic type have been legal since generics arrived. Separately, aliases may themselves take type parameters (`type Set[T comparable] = map[T]struct{}`), which is useful for naming a generic shape — but that alias, too, is written with type arguments wherever it is used. ## Where this bites in practice - **Struct fields and function signatures** repeat the type arguments everywhere: a `Cache[string, []byte]` threaded through five layers is written five times, and changing the value type is a five-file edit. That is a real argument for wrapping deep instantiations in a named type or alias. - **Nested generics** compound quickly: `Result[map[string]Stack[int]]` is legal and unreadable, and reviewers should push back on it. - **Method sets** are per-instantiation: `Stack[int]` and `Stack[string]` are distinct types with no relationship, so neither is assignable to the other and neither satisfies an interface on behalf of the other. ## What an interviewer is checking Whether you can state the boundary crisply — inference is a property of calls, not of types — and whether you have drawn the design conclusion from it: the readability of a generic container in Go is mostly decided by the constructor you give it.