Generic Functions

One Idea, Many Input Types

Imagine a conveyor belt in a factory. One day it moves books. The next day it moves boxes. The next day it moves phone cases. The belt's job has not changed: take each item, pass it through a step, and build a new line of output. Only the item type changed.

Generic functions are Go's way of describing that kind of reusable shape. You are not saying, 'I do not care about types.' You are saying, 'this operation has the same structure for many types, so let me express that structure once.'

Reading the Syntax

The only new visual feature on a generic function is the square-bracket section after the function name. Read it slowly until it feels ordinary.

1. Identity is the function name.
2. [T any] declares one type parameter named T with the very loose constraint any.
3. value T means the parameter's type is whatever concrete type T becomes for that call.
4. The return type is also T, so the output type always matches the input type.

Calling Generic Functions

You can call a generic function in two ways. Sometimes you write the type argument yourself. Sometimes Go can infer it from the values you pass in.

That gives you a practical rule: Go can infer a type argument when enough information appears in the call's ordinary arguments. If no ordinary argument mentions the type, the compiler has nothing concrete to infer from.

Three Useful Utilities

Now let's move beyond toy examples and write the sort of helpers people actually reach for in day-to-day code.

Notice how each function expresses a reusable pattern rather than a domain-specific story. That is one of the best homes for generics: small, broadly useful operations whose structure stays the same while the concrete types vary.

Tracing Map Step by Step

Let's trace one real Map call with concrete values. This is where generic functions stop feeling abstract and start feeling mechanical in a good way.

Quiz

Practice

Summary

• Generic functions add a square-bracket type-parameter section after the function name.
• Go can often infer type arguments from the call's normal arguments.
• If a call gives the compiler no way to infer the type, you must write the type argument explicitly.
• Functions like Map, Filter, and Contains are strong generic candidates because their structure stays the same across many concrete types.
• A generic function still runs with real concrete types and real values at each call site.