Type Parameters And Generics

Generics in Go provide a powerful way to write reusable and type-safe code. They allow developers to write functions and data structures that can work with different types, without sacrificing type safety. With generics, we can create flexible and efficient algorithms that can be used with various data types, reducing code duplication and improving code maintainability. Generics enable us to write more generic and abstract code, making our programs more flexible and adaptable to different scenarios.

Generics allow us to write functions and types that work with multiple types while maintaining compile-time type safety.

Generics were introduced in Go 1.18 to solve problems that interfaces alone couldn’t address elegantly. They provide a way to write reusable code without sacrificing performance or type safety.

Before we dive into why generics are useful, let’s understand the basic syntax. Generic functions use square brackets [] to declare type parameters:

func Name[T any](parameters) (returns) {
	// ...
}

Let’s break down this syntax:

1. Function Name: Name is the regular function name
2. Type Parameters: [T any] declares a type parameter called T
   • T is a placeholder for the actual type that will be used
   • any is a constraint meaning T can be any type
3. Parameters: Use T in the parameter list to refer to the generic type
4. Returns: Can also use T in the return type

Here T is a type parameter that can be any type. Let’s see this in action:

func Echo[T any](input T) T {
	return input
}

package main

import "fmt"

// section: function
func Echo[T any](input T) T {
	return input
}

// section: function

func main() {
	// Works with any type
	fmt.Println(Echo("Hello, World!"))
	fmt.Println(Echo(42))
	fmt.Println(Echo(3.14))
	fmt.Println(Echo(true))
}

Let’s understand what’s happening here:

1. Generic Function: Echo[T any](input T) T accepts any type T
2. Type Parameter Usage: The parameter input is of type T
3. Type Inference: When we call Echo("Hello, World!"), Go infers that T is string
4. Multiple Types: The same function works with strings, integers, and booleans

This function can work with any type - strings, integers, booleans, or custom types.

But you might be wondering: “Why is this better than just using interfaces?”

Great question! While interfaces are powerful for many use cases, they have limitations when we need to maintain type safety across operations. The simple example we just saw doesn’t really show the power of generics.

Let’s explore a more realistic scenario that demonstrates why generics are essential.

Consider a function that returns the keys of a map. Using interfaces, we might write:

func Keys(m map[any]any) []any {
	keys := make([]any, 0, len(m))
	for k := range m {
		keys = append(keys, k)
	}
	return keys
}

package main

import "fmt"

// section: function
func Keys(m map[any]any) []any {
	keys := make([]any, 0, len(m))
	for k := range m {
		keys = append(keys, k)
	}
	return keys
}

// section: function

func main() {
	// section: usage
	// This is cumbersome - we lose type safety
	stringIntMap := map[string]int{"a": 1, "b": 2}

	// We need to convert to map[any]any
	anyMap := make(map[any]any)
	for k, v := range stringIntMap {
		anyMap[k] = v
	}

	keys := Keys(anyMap)
	fmt.Println("Keys:", keys)

	// We need to assert types when using the results
	for _, key := range keys {
		if strKey, ok := key.(string); ok {
			fmt.Println("String key:", strKey)
		}
	}
	// section: usage
}

Let’s break down what’s happening here:

1. Function Signature: We accept a map with any keys and any values
2. Key Extraction: We iterate through the map and collect all keys into a slice
3. Return Type: We return []any because we don’t know the specific type of keys

While this works, it’s difficult to use because we lose type safety:

// This is cumbersome - we lose type safety
stringIntMap := map[string]int{"a": 1, "b": 2}

// We need to convert to map[any]any
anyMap := make(map[any]any)
for k, v := range stringIntMap {
	anyMap[k] = v
}

keys := Keys(anyMap)
fmt.Println("Keys:", keys)

// We need to assert types when using the results
for _, key := range keys {
	if strKey, ok := key.(string); ok {
		fmt.Println("String key:", strKey)
	}
}

package main

import "fmt"

// section: function
func Keys(m map[any]any) []any {
	keys := make([]any, 0, len(m))
	for k := range m {
		keys = append(keys, k)
	}
	return keys
}

// section: function

func main() {
	// section: usage
	// This is cumbersome - we lose type safety
	stringIntMap := map[string]int{"a": 1, "b": 2}

	// We need to convert to map[any]any
	anyMap := make(map[any]any)
	for k, v := range stringIntMap {
		anyMap[k] = v
	}

	keys := Keys(anyMap)
	fmt.Println("Keys:", keys)

	// We need to assert types when using the results
	for _, key := range keys {
		if strKey, ok := key.(string); ok {
			fmt.Println("String key:", strKey)
		}
	}
	// section: usage
}

Notice the problems with this approach:

1. Type Conversion: We must convert our typed map to map[any]any before calling the function
2. Loss of Type Information: The returned slice is []any, not []string
3. Type Assertions: We need to assert types when using the results (key.(string))
4. Runtime Errors: Type assertions can panic if we get the types wrong
5. No Compile-Time Safety: The compiler can’t help us catch type-related errors

This is exactly the kind of problem generics were designed to solve - maintaining type safety while providing flexibility.

Now let’s see how generics elegantly solve this problem while maintaining type safety:

func Keys[K comparable, V any](m map[K]V) []K {
	keys := make([]K, 0, len(m))
	for k := range m {
		keys = append(keys, k)
	}
	return keys
}

package main

import "fmt"

// section: function
func Keys[K comparable, V any](m map[K]V) []K {
	keys := make([]K, 0, len(m))
	for k := range m {
		keys = append(keys, k)
	}
	return keys
}

// section: function

func main() {
	// section: usage
	// Much cleaner - type safety is maintained
	stringIntMap := map[string]int{"a": 1, "b": 2, "c": 3}
	intStringMap := map[int]string{1: "one", 2: "two", 3: "three"}

	stringKeys := Keys(stringIntMap)
	intKeys := Keys(intStringMap)

	fmt.Printf("String Keys\t Type: %[1]T\tKeys: %[1]v\n", stringKeys)
	fmt.Printf("Int Keys\t Type: %[1]T\tKeys: %[1]v\n", intKeys)

	// No type assertions needed!
	for _, key := range stringKeys {
		fmt.Printf("Key: %s, Value: %d\n", key, stringIntMap[key])
	}
	// section: usage
}

Let’s examine the generic function signature:

1. Type Parameters: [K comparable, V any] declares two type parameters
   • K is the key type, constrained to comparable (can be used with == and !=)
   • V is the value type, with no constraints (any)
2. Function Parameter: m map[K]V accepts a map with keys of type K and values of type V
3. Return Type: []K returns a slice of keys with the same type as the map’s keys
4. Type Safety: The compiler ensures all types match throughout the function

Now we can use this function with any map type:

// Much cleaner - type safety is maintained
stringIntMap := map[string]int{"a": 1, "b": 2, "c": 3}
intStringMap := map[int]string{1: "one", 2: "two", 3: "three"}

stringKeys := Keys(stringIntMap)
intKeys := Keys(intStringMap)

fmt.Printf("String Keys\t Type: %[1]T\tKeys: %[1]v\n", stringKeys)
fmt.Printf("Int Keys\t Type: %[1]T\tKeys: %[1]v\n", intKeys)

// No type assertions needed!
for _, key := range stringKeys {
	fmt.Printf("Key: %s, Value: %d\n", key, stringIntMap[key])
}

package main

import "fmt"

// section: function
func Keys[K comparable, V any](m map[K]V) []K {
	keys := make([]K, 0, len(m))
	for k := range m {
		keys = append(keys, k)
	}
	return keys
}

// section: function

func main() {
	// section: usage
	// Much cleaner - type safety is maintained
	stringIntMap := map[string]int{"a": 1, "b": 2, "c": 3}
	intStringMap := map[int]string{1: "one", 2: "two", 3: "three"}

	stringKeys := Keys(stringIntMap)
	intKeys := Keys(intStringMap)

	fmt.Printf("String Keys\t Type: %[1]T\tKeys: %[1]v\n", stringKeys)
	fmt.Printf("Int Keys\t Type: %[1]T\tKeys: %[1]v\n", intKeys)

	// No type assertions needed!
	for _, key := range stringKeys {
		fmt.Printf("Key: %s, Value: %d\n", key, stringIntMap[key])
	}
	// section: usage
}

Notice the improvements:

1. No Type Conversion: We can pass our maps directly without converting to map[any]any
2. Type Safety: The returned slices have the correct types ([]string and []int)
3. No Type Assertions: We can use the keys directly without type assertions
4. Compile-Time Checking: The compiler catches type errors at compile time
5. Clean Code: The usage is much cleaner and more intuitive

The beauty of this approach is that we maintain complete type safety while gaining flexibility. But generics can do even more than this simple example.

You might have noticed we used comparable as a constraint for the map key type K. This is a special built-in constraint in Go that’s essential for working with maps and certain operations. Let’s understand what it means and why it’s important.

What is Comparable?

The comparable constraint is a predeclared identifier in Go (like int, string, any) that represents all types that can be compared using the == and != operators. This is crucial for map keys because Go needs to compare keys to determine if they already exist in the map.

Types That Satisfy Comparable:

✅ Always Comparable:

• All boolean types (bool)
• All numeric types (int, int8, int16, int32, int64, uint, uint8, uint16, uint32, uint64, float32, float64, complex64, complex128)
• All string types (string)
• Pointer types (*T)
• Channel types (chan T)
• Interface types (can be compared to nil or other interface values)
• Arrays of comparable types ([N]T where T is comparable)
• Structs where all fields are comparable

❌ Never Comparable:

• Slices ([]T)
• Maps (map[K]V)
• Functions (func())

Why Map Keys Must Be Comparable:

Maps in Go are implemented as hash tables. When you insert or look up a value, Go needs to:

1. Hash the key to find the bucket
2. Compare the key with existing keys in that bucket using ==

Without the ability to compare keys, Go couldn’t determine if a key already exists in the map.

Example with Different Comparable Types:

// All these work because the key types are comparable
var intMap map[int]string              // int is comparable
var stringMap map[string]int           // string is comparable
var ptrMap map[*User]string           // pointers are comparable
var structMap map[Point]string        // structs with comparable fields are comparable

// These would cause compile errors
// var sliceMap map[[]int]string      // ❌ slices are not comparable
// var mapMap map[map[string]int]bool // ❌ maps are not comparable

When to Use Comparable vs Ordered:

• Use comparable: When you need to check equality (==, !=) - perfect for map keys, checking if values are equal
• Use constraints.Ordered: When you need ordering comparisons (<, <=, >=, >) - for sorting, finding min/max values

constraints.Ordered is more restrictive than comparable - all ordered types are comparable, but not all comparable types are ordered (e.g., complex numbers are comparable but not ordered).

Important: Go generics are NOT implemented using traditional monomorphization (code generation) like C++ templates or Rust. This is a common misconception.

Instead, Go uses a hybrid approach called “GCShape stenciling with dictionaries”:

1. GCShape Grouping: Types with the same underlying type or all pointer types share the same compiled function
2. Dictionary Passing: Every generic function call receives a hidden dictionary parameter (passed in register AX on x86_64)
3. Runtime Resolution: Method calls and type operations use the dictionary to resolve types at runtime

Real Example of GCShape Grouping

What you write:

func process[T int | string | *User](data T) {
    // ... some processing
}

func main() {
    process(42)           // int
    process("hello")      // string  
    process(&User{})      // *User
    process(&Product{})   // *Product
}

What the compiler actually generates:

// Shape for int (distinct from string)
func process[go.shape.int_0](dict *Dictionary, data go.shape.int_0)

// Shape for string (distinct from int)  
func process[go.shape.string_0](dict *Dictionary, data go.shape.string_0)

// Shape for ALL pointer types (*User, *Product, *int, *string, etc.)
func process[go.shape.*uint8_0](dict *Dictionary, data go.shape.*uint8_0)

The Dictionary Contains:

• Runtime type information for each type parameter
• Method tables (itabs) for calling methods on generic types
• Type conversion information for interface conversions

Performance Implications:

• Compile-time: Faster than full monomorphization
• Runtime: Can be slower than interfaces due to dictionary lookups
• Method calls: Require double indirection (dictionary → itab → method)

Source: DeepSource Go 1.18 Generics Implementation

For more complex scenarios, we can specify multiple type parameters in a single function:

func Transform[T any, U any](input T, transformer func(T) U) U {
	return transformer(input)
}

package main

import "fmt"

// section: function
func Transform[T any, U any](input T, transformer func(T) U) U {
	return transformer(input)
}

// section: function

func main() {
	// section: usage
	// Transform string to int
	result1 := Transform("hello", func(s string) int {
		return len(s)
	})
	fmt.Println("String length:", result1)

	// Transform int to string
	result2 := Transform(42, func(i int) string {
		return fmt.Sprintf("Number: %d", i)
	})
	fmt.Println("Formatted number:", result2)

	// Transform int to bool
	result3 := Transform(10, func(i int) bool {
		return i%2 == 0
	})
	fmt.Println("Is even:", result3)
	// section: usage
}

Let’s break down this function with multiple type parameters:

1. Type Parameters: [T any, U any] declares two separate type parameters

   • T (input type) can be any type - no constraints
   • U (output type) can be any type - no constraints

2. Function Parameters:

   • input T - a value of type T to transform
   • transformer func(T) U - a function that converts from type T to type U

3. Return Type: U - returns a value of type U (the transformed result)

4. Type Relationships: The compiler ensures that the input type matches the transformer function’s input parameter, and the return type matches the transformer function’s return type

This allows us to work with different input and output types:

// Transform string to int
result1 := Transform("hello", func(s string) int {
	return len(s)
})
fmt.Println("String length:", result1)

// Transform int to string
result2 := Transform(42, func(i int) string {
	return fmt.Sprintf("Number: %d", i)
})
fmt.Println("Formatted number:", result2)

// Transform int to bool
result3 := Transform(10, func(i int) bool {
	return i%2 == 0
})
fmt.Println("Is even:", result3)

package main

import "fmt"

// section: function
func Transform[T any, U any](input T, transformer func(T) U) U {
	return transformer(input)
}

// section: function

func main() {
	// section: usage
	// Transform string to int
	result1 := Transform("hello", func(s string) int {
		return len(s)
	})
	fmt.Println("String length:", result1)

	// Transform int to string
	result2 := Transform(42, func(i int) string {
		return fmt.Sprintf("Number: %d", i)
	})
	fmt.Println("Formatted number:", result2)

	// Transform int to bool
	result3 := Transform(10, func(i int) bool {
		return i%2 == 0
	})
	fmt.Println("Is even:", result3)
	// section: usage
}

Notice how the function works seamlessly with different type transformations:

1. First Call: Transform("hello", func(s string) int { return len(s) }) - transforms string to int (length)
2. Second Call: Transform(42, func(i int) string { return fmt.Sprintf("Number: %d", i) }) - transforms int to string (formatting)
3. Third Call: Transform(10, func(i int) bool { return i%2 == 0 }) - transforms int to bool (even check)
4. Type Safety: Each call returns the correct output type without any type assertions
5. Flexibility: One function handles multiple input-output type combinations

So far we’ve been using any as our constraint, which accepts any type. But what if we want to be more specific about which types are allowed?

We can create custom constraints to be more specific about which types are allowed:

type Numeric interface {
	int | int32 | int64 | float32 | float64
}

package main

import "fmt"

// section: constraint
type Numeric interface {
	int | int32 | int64 | float32 | float64
}

// section: constraint

// section: function
func Add[T Numeric](a, b T) T {
	return a + b
}

func Multiply[T Numeric](a, b T) T {
	return a * b
}

// section: function

func main() {
	// Works with various numeric types
	fmt.Println("Int addition:", Add(5, 3))
	fmt.Println("Float addition:", Add(3.14, 2.86))
	fmt.Println("Int multiplication:", Multiply(4, 7))
	fmt.Println("Float multiplication:", Multiply(2.5, 1.5))
}

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

func Multiply[T Numeric](a, b T) T {
	return a * b
}

package main

import "fmt"

// section: constraint
type Numeric interface {
	int | int32 | int64 | float32 | float64
}

// section: constraint

// section: function
func Add[T Numeric](a, b T) T {
	return a + b
}

func Multiply[T Numeric](a, b T) T {
	return a * b
}

// section: function

func main() {
	// Works with various numeric types
	fmt.Println("Int addition:", Add(5, 3))
	fmt.Println("Float addition:", Add(3.14, 2.86))
	fmt.Println("Int multiplication:", Multiply(4, 7))
	fmt.Println("Float multiplication:", Multiply(2.5, 1.5))
}

We can use the | operator to create union constraints that allow multiple types:

type StringOrInt interface {
	string | int
}

package main

import "fmt"

// section: constraint
type StringOrInt interface {
	string | int
}
// section: constraint

func main() {
	// section: usage
	process := func[T StringOrInt](input T) {
		switch v := any(input).(type) {
		case string:
			fmt.Printf("Processing string: %s (length: %d)\n", v, len(v))
		case int:
			fmt.Printf("Processing int: %d (doubled: %d)\n", v, v*2)
		}
	}
	
	process("hello")
	process(42)
	// section: usage
}

process := func[T StringOrInt](input T) {
	switch v := any(input).(type) {
	case string:
		fmt.Printf("Processing string: %s (length: %d)\n", v, len(v))
	case int:
		fmt.Printf("Processing int: %d (doubled: %d)\n", v, v*2)
	}
}

process("hello")
process(42)

package main

import "fmt"

// section: constraint
type StringOrInt interface {
	string | int
}
// section: constraint

func main() {
	// section: usage
	process := func[T StringOrInt](input T) {
		switch v := any(input).(type) {
		case string:
			fmt.Printf("Processing string: %s (length: %d)\n", v, len(v))
		case int:
			fmt.Printf("Processing int: %d (doubled: %d)\n", v, v*2)
		}
	}
	
	process("hello")
	process(42)
	// section: usage
}

When working with union constraints, you might need to handle each type differently within your generic function. Notice in the example above how we use a type switch to determine which specific type we’re working with:

switch v := any(input).(type) {
case string:
    // Handle string specifically
case int:
    // Handle int specifically
}

Why Type Assertions with Generics?

1. Type-Specific Operations: When different types in your constraint need different handling

   • Strings might need length checks
   • Numbers might need arithmetic operations
   • Custom types might need method calls

2. Optimization: You can provide optimized code paths for specific types

   • Fast path for built-in types
   • Special handling for custom types

3. Behavior Customization: Different types can have completely different behaviors

   • Formatting output differently based on type
   • Validation rules that differ by type

Important Considerations:

• The Conversion: any(input).(type) converts the generic type to any so we can use a type switch
• Type Safety Still Applies: The type switch can only match types allowed by the constraint
• Manual Coverage Required: You must explicitly handle all types in the constraint or include a default case - Go does not perform exhaustiveness checking on type switches
• When Not to Use: If all types can be handled the same way, avoid type switching - it defeats the purpose of generics

Alternative Pattern - Using the Type Directly:

For operations that work across all types in your constraint, you don’t need type assertions:

func Double[T StringOrInt](input T) string {
    // This works because both string and int can be formatted
    return fmt.Sprintf("%v%v", input, input)
}

One of the key benefits of generics with constraints is that the compiler enforces type safety at compile time. This prevents runtime errors that could occur with empty interfaces.

Given this function:

type Number interface {
	int | float64
}

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

package main

import "fmt"

// section: constraint
type Number interface {
	int | float64
}

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

// section: constraint

// section: violation
func main() {
	// This works fine - int satisfies Number constraint
	result1 := Add(5, 3)
	fmt.Println("5 + 3 =", result1)

	// This works fine - float64 satisfies Number constraint
	result2 := Add(2.5, 1.3)
	fmt.Println("2.5 + 1.3 =", result2)

	// This will cause a compile error - string doesn't satisfy Number constraint
	result3 := Add("hello", "world")
	fmt.Println("Concatenation:", result3)
}

// section: violation

// section: error
// ./main.go:23:19: string does not satisfy Number (string not in int | float64)

// section: error

Let’s see what happens when we try to use a type that doesn’t satisfy our constraint:

func main() {
	// This works fine - int satisfies Number constraint
	result1 := Add(5, 3)
	fmt.Println("5 + 3 =", result1)

	// This works fine - float64 satisfies Number constraint
	result2 := Add(2.5, 1.3)
	fmt.Println("2.5 + 1.3 =", result2)

	// This will cause a compile error - string doesn't satisfy Number constraint
	result3 := Add("hello", "world")
	fmt.Println("Concatenation:", result3)
}

package main

import "fmt"

// section: constraint
type Number interface {
	int | float64
}

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

// section: constraint

// section: violation
func main() {
	// This works fine - int satisfies Number constraint
	result1 := Add(5, 3)
	fmt.Println("5 + 3 =", result1)

	// This works fine - float64 satisfies Number constraint
	result2 := Add(2.5, 1.3)
	fmt.Println("2.5 + 1.3 =", result2)

	// This will cause a compile error - string doesn't satisfy Number constraint
	result3 := Add("hello", "world")
	fmt.Println("Concatenation:", result3)
}

// section: violation

// section: error
// ./main.go:23:19: string does not satisfy Number (string not in int | float64)

// section: error

Here’s what’s happening in this example:

1. Valid Constraint: StringType satisfies the ~string constraint because its underlying type is string
2. Invalid Constraint: IntType does not satisfy the ~string constraint because its underlying type is int, not string
3. Function Call: We try to call processString with both types

The compiler will catch this error and prevent the code from compiling:

// ./main.go:23:19: string does not satisfy Number (string not in int | float64)

package main

import "fmt"

// section: constraint
type Number interface {
	int | float64
}

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

// section: constraint

// section: violation
func main() {
	// This works fine - int satisfies Number constraint
	result1 := Add(5, 3)
	fmt.Println("5 + 3 =", result1)

	// This works fine - float64 satisfies Number constraint
	result2 := Add(2.5, 1.3)
	fmt.Println("2.5 + 1.3 =", result2)

	// This will cause a compile error - string doesn't satisfy Number constraint
	result3 := Add("hello", "world")
	fmt.Println("Concatenation:", result3)
}

// section: violation

// section: error
// ./main.go:23:19: string does not satisfy Number (string not in int | float64)

// section: error

Key benefits of compile-time constraint checking:

1. Early Detection: Errors are caught at compile time, not runtime
2. Clear Error Messages: The compiler tells us exactly what’s wrong and why
3. No Runtime Panics: Unlike with empty interfaces, invalid types can’t cause runtime crashes
4. Better IDE Support: IDEs can provide better autocompletion and error highlighting
5. Confidence: You know if your code compiles, the type constraints are satisfied

This is much better than runtime panics you might get with empty interfaces, where errors only surface when the code is executed and could crash your running application.

The ~ operator allows us to accept types based on a specific underlying type:

type UserID int
type ProductID int
type Score float64

package main

import "fmt"

// section: types
type UserID int
type ProductID int
type Score float64
// section: types

// section: constraint
type IntegerID interface {
	~int
}

type FloatScore interface {
	~float64
}
// section: constraint

func main() {
	// section: usage
	processID := func[T IntegerID](id T) {
		fmt.Printf("Processing ID: %v\n", id)
	}
	
	processScore := func[T FloatScore](score T) {
		fmt.Printf("Processing score: %.2f\n", score)
	}
	
	var userID UserID = 123
	var productID ProductID = 456
	var score Score = 95.5
	
	processID(userID)
	processID(productID)
	processScore(score)
	// section: usage
}

Here we define custom types that have int and float64 as their underlying types. Without generics, we’d need separate functions for each type.

type IntegerID interface {
	~int
}

type FloatScore interface {
	~float64
}

package main

import "fmt"

// section: types
type UserID int
type ProductID int
type Score float64
// section: types

// section: constraint
type IntegerID interface {
	~int
}

type FloatScore interface {
	~float64
}
// section: constraint

func main() {
	// section: usage
	processID := func[T IntegerID](id T) {
		fmt.Printf("Processing ID: %v\n", id)
	}
	
	processScore := func[T FloatScore](score T) {
		fmt.Printf("Processing score: %.2f\n", score)
	}
	
	var userID UserID = 123
	var productID ProductID = 456
	var score Score = 95.5
	
	processID(userID)
	processID(productID)
	processScore(score)
	// section: usage
}

Let’s understand what these constraints do:

1. ~int Constraint: The ~ (tilde) operator means “any type whose underlying type is int”

   • This includes int itself, but also custom types like UserID and ProductID
   • Without ~, the constraint would only accept exactly int, not custom types based on int

2. ~float64 Constraint: Similarly, this accepts any type whose underlying type is float64

   • This includes float64 itself and custom types like Score

processID := func[T IntegerID](id T) {
	fmt.Printf("Processing ID: %v\n", id)
}

processScore := func[T FloatScore](score T) {
	fmt.Printf("Processing score: %.2f\n", score)
}

var userID UserID = 123
var productID ProductID = 456
var score Score = 95.5

processID(userID)
processID(productID)
processScore(score)

package main

import "fmt"

// section: types
type UserID int
type ProductID int
type Score float64
// section: types

// section: constraint
type IntegerID interface {
	~int
}

type FloatScore interface {
	~float64
}
// section: constraint

func main() {
	// section: usage
	processID := func[T IntegerID](id T) {
		fmt.Printf("Processing ID: %v\n", id)
	}
	
	processScore := func[T FloatScore](score T) {
		fmt.Printf("Processing score: %.2f\n", score)
	}
	
	var userID UserID = 123
	var productID ProductID = 456
	var score Score = 95.5
	
	processID(userID)
	processID(productID)
	processScore(score)
	// section: usage
}

Notice what happens in the usage:

1. Type Flexibility: Both UserID and ProductID can be used with processID because they both have int as their underlying type
2. Type Safety: We still maintain type safety - we can’t accidentally pass a UserID where a ProductID is expected in our business logic
3. Code Reuse: One generic function works with multiple related types instead of needing separate functions for each type

This is particularly useful when you have domain-specific types that share common operations but need to remain distinct types in your API.

Go provides a golang.org/x/exp/constraints package with predefined constraints for common use cases:

"golang.org/x/exp/constraints"

package main

import (
	"fmt"
	// section: import
	"golang.org/x/exp/constraints"
	// section: import
)

// section: usage
// Using constraints.Signed for signed integers
func max[T constraints.Signed](a, b T) T {
	if a > b {
		return a
	}
	return b
}

// Using constraints.Unsigned for unsigned integers
func min[T constraints.Unsigned](a, b T) T {
	if a < b {
		return a
	}
	return b
}

// Using constraints.Float for floating point numbers
func average[T constraints.Float](numbers ...T) T {
	var sum T
	for _, num := range numbers {
		sum += num
	}
	return sum / T(len(numbers))
}

// section: usage

func main() {
	// section: usage
	fmt.Println("Max of -5 and 10:", max(-5, 10))
	fmt.Println("Min of 3 and 7:", min(uint(3), uint(7)))
	fmt.Println("Average of 1.5, 2.5, 3.5:", average(1.5, 2.5, 3.5))
	// section: usage
}

// Using constraints.Signed for signed integers
func max[T constraints.Signed](a, b T) T {
	if a > b {
		return a
	}
	return b
}

// Using constraints.Unsigned for unsigned integers
func min[T constraints.Unsigned](a, b T) T {
	if a < b {
		return a
	}
	return b
}

// Using constraints.Float for floating point numbers
func average[T constraints.Float](numbers ...T) T {
	var sum T
	for _, num := range numbers {
		sum += num
	}
	return sum / T(len(numbers))
}

	fmt.Println("Max of -5 and 10:", max(-5, 10))
	fmt.Println("Min of 3 and 7:", min(uint(3), uint(7)))
	fmt.Println("Average of 1.5, 2.5, 3.5:", average(1.5, 2.5, 3.5))