1.7Дженерики

Разберём параметры типов через множества допустимых типов и сравним дженерик с интерфейсом поведения.

Зачем они вообще появились

До 1.18 у Go было ровно три способа написать «одно и то же для разных типов», и каждый чем-то плох. Дженерики закрывают конкретный, довольно узкий пробел: статически типизированный код, одинаковый по структуре, но разный по типу элементов. Не «ООП» и не «шаблоны на все случаи жизни». Именно это.

Синтаксис: параметры типа

Параметры типа объявляются в квадратных скобках сразу после имени функции или типа. Каждый параметр состоит из имени и констрейнта. Констрейнт обязателен: даже «любой тип» пишется явно как any (это алиас для interface{}, добавленный в 1.18 ради читаемости).

// Дженерик-функция: два параметра типа, оба используются в обычной сигнатуре
func Map[E any, R any](s []E, f func(E) R) []R {
    r := make([]R, 0, len(s))    // R можно использовать как обычный тип
    for _, v := range s {
        r = append(r, f(v))
    }
    return r
}

// Вызов: типы выводятся из аргументов
names := Map([]int{1, 2, 3}, strconv.Itoa)   // []string

// Инстанцируем явно, когда вывести не из чего
parse := Map[string, int]                    // получили обычную func([]string, func(string) int) []int

// Дженерик-тип: параметры типа у объявления типа
type Stack[T any] struct {
    items []T
}

// Методы дженерик-типа перечисляют параметры получателя.
// До Go 1.27 добавить к ним свои параметры типа было нельзя; с 1.27 можно (см. ниже).
func (s *Stack[T]) Push(v T) { s.items = append(s.items, v) }
func (s *Stack[T]) Pop() (T, bool) {
    var zero T                                // нулевое значение параметра типа - только так
    if len(s.items) == 0 {
        return zero, false
    }
    v := s.items[len(s.items)-1]
    s.items = s.items[:len(s.items)-1]
    return v, true
}

// Дженерик-тип всегда используют с аргументами типа
var st Stack[string]                          // ок
// var bad Stack                              // ошибка: cannot use generic type Stack without instantiation

Констрейнты: интерфейс как множество типов

Формулировка, которую стоит держать наготове: в Go 1.18 изменилось само определение интерфейса. Раньше интерфейс задавал множество методов. Теперь он задаёт множество типов, а список методов просто один из способов это множество задать. interface{ Read([]byte) (int, error) } задаёт множество всех типов, у которых есть такой метод. interface{ int | string } перечисляет ровно два типа. Констрейнтом называют интерфейс, поставленный в позицию параметра типа.

Тильда ~: почему без неё всё ломается

int в констрейнте означает ровно тип int, ни строчкой больше. А в реальном коде сплошь и рядом встречаются именованные типы: type UserID int, type Weekday int, type Kilometers float64. Такой тип не удовлетворяет констрейнту int, потому что это другой тип. ~int читается как «любой тип, у которого underlying type совпадает с int» и включает и сам int, и все производные от него именованные типы.

type Strict interface{ int }        // множество = {int}
type Loose  interface{ ~int }       // множество = {int, UserID, Weekday, ...}

type UserID int

func StrictSum[T Strict](xs []T) T { var s T; for _, x := range xs { s += x }; return s }
func LooseSum[T Loose](xs []T)  T { var s T; for _, x := range xs { s += x }; return s }

ids := []UserID{1, 2, 3}
// StrictSum(ids)   // ошибка: UserID does not satisfy Strict (possibly missing ~ for int)
LooseSum(ids)       // ок → UserID(6)

// Ограничение тильды: справа от ~ должен стоять тип, чей underlying - он сам.
// type MyInt = ~int          // нельзя: ~ вне интерфейса
// interface{ ~UserID }       // ошибка: invalid use of ~ (underlying type of UserID is int)

comparable и constraints.Ordered

comparable остаётся единственным встроенным констрейнтом, который не выразить синтаксисом объединения: множество «типов, у которых == определён и не паникует» включает все числа, строки, булевы, указатели, каналы, интерфейсы, а ещё массивы и структуры из таких типов. Набор выходит бесконечный, его задаёт рекурсивное правило. Поэтому он зашит в компилятор.

// comparable нужен там, где значение идёт ключом мапы или сравнивается
func Unique[T comparable](s []T) []T {
    seen := make(map[T]struct{}, len(s))     // ключ мапы обязан быть comparable
    out := make([]T, 0, len(s))
    for _, v := range s {
        if _, ok := seen[v]; !ok {
            seen[v] = struct{}{}
            out = append(out, v)
        }
    }
    return out
}

Unique([]int{1, 1, 2})                       // ок
Unique([]struct {
    A int
}{{1}, {1}})          // ок - структура из comparable полей
// Unique([][]byte{{1}})                     // ошибка: []byte does not satisfy comparable

constraints.Ordered живёт в golang.org/x/exp/constraints, то есть вне стандартной библиотеки, и это осознанное решение. Команда Go решила не фиксировать в stdlib набор «удобных» констрейнтов, пока не станет ясно, какие из них действительно нужны: однажды попав в std, они попадают под гарантию совместимости навсегда. Практический ответ на собесе: «в проде я не тяну x/exp ради трёх строк, объявляю свой Ordered локально, это ровно один интерфейс».

// Это ровно x/exp/constraints, можно скопировать к себе
type Signed   interface{ ~int | ~int8 | ~int16 | ~int32 | ~int64 }
type Unsigned interface{ ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr }
type Integer  interface{ Signed | Unsigned }          // объединение констрейнтов
type Float    interface{ ~float32 | ~float64 }
type Ordered  interface{ Integer | Float | ~string }  // всё, где работают < и >

// Complex в Ordered не входит: комплексные числа не упорядочены.

func Max[T Ordered](a, b T) T { if a > b { return a }; return b }
func Clamp[T Ordered](v, lo, hi T) T {
    if v < lo { return lo }
    if v > hi { return hi }
    return v
}

Собственные констрейнты через интерфейсы

Констрейнт остаётся обычным интерфейсом, поэтому собирать его можно из чего угодно: методов, объединений типов, других констрейнтов. Три рабочих приёма, которые реально встречаются в проде.

// 1. Метод + тип одновременно (пересечение множеств)
type Stringish interface {
    ~string
    Len() int        // тип обязан иметь underlying string и метод Len
}

// 2. Констрейнт «указатель на T»: иначе это не выразить.
//    Классика: функция должна создать значение и вызвать на нём pointer-метод.
type Unmarshaler[T any] interface {
    *T                       // один терм: указатель на T
    json.Unmarshaler
}

func DecodeAll[T any, PT Unmarshaler[T]](raws [][]byte) ([]T, error) {
    out := make([]T, 0, len(raws))
    for _, raw := range raws {
        var v T
        if err := PT(&v).UnmarshalJSON(raw); err != nil {   // &v имеет тип *T = PT
            return nil, err
        }
        out = append(out, v)
    }
    return out, nil
}
// Вызов: DecodeAll[User](raws) - PT выводится из T автоматически

// 3. Констрейнт на «слайс своего типа» сохраняет именованный тип результата
type Slice[E any] interface{ ~[]E }

func Filter[S Slice[E], E any](s S, keep func(E) bool) S {
    out := make(S, 0, len(s))     // тип результата S, а не []E
    for _, v := range s {
        if keep(v) { out = append(out, v) }
    }
    return out
}

type IDs []int
var ids IDs = []int{1, 2, 3}
r := Filter(ids, func(i int) bool { return i > 1 })   // r имеет тип IDs, а не []int

Вывод типов: когда работает и когда нет

Вывод типов в Go намеренно ограничен. Он идёт только «снизу вверх» от типов аргументов (function argument type inference) и дополняется выводом из самих констрейнтов (constraint type inference). Из типа результата, из контекста присваивания и из тела функции Go не выводит ничего, в отличие от Rust или Haskell. Выбор сознательный: так проще, и сообщения об ошибках предсказуемее.

// Классический промах вывода
func New[T any]() *T { return new(T) }
// p := New()          // ошибка: cannot infer T
p := New[User]()       // ок

// Ещё один: reduce, где аккумулятор другого типа
func Reduce[E, A any](s []E, init A, f func(A, E) A) A { ... }
sum := Reduce([]int{1,2,3}, 0, func(a, e int) int { return a + e })   // ок: A выведен из init

// А так не выведется, потому что тип литерала неизвестен до вывода A:
// Reduce([]int{1,2,3}, 0, func(a, e) int { return a + e })  // так нельзя: у литерала функции типы параметров обязательны

// Go 1.21 заметно усилил вывод: теперь работает передача дженерик-функции
// в дженерик-функцию без явных аргументов типа.
res := Map([]int{1,2,3}, strconv.Itoa)      // 1.18+
srt := slices.SortedFunc(maps.Keys(m), cmp.Compare)   // 1.23, вывод через несколько уровней

Дженерики или интерфейсы: аргументы обеих сторон

Правильный ответ здесь не «дженерики лучше». Инструменты решают разные задачи: интерфейс абстрагирует поведение (что объект умеет), дженерик абстрагирует тип данных (с чем работает алгоритм). Путаница начинается там, где обе абстракции формально применимы.

Когда дженерики - плохой выбор

• Слой репозитория / storage. Repository[T] выглядит красиво ровно до первого метода FindByEmail. Дальше начинается либо union-констрейнт из всех сущностей, либо рефлексия для имени таблицы, либо интерфейс сбоку. Выходит хуже, чем три честных репозитория.
• Там, где нужен мок. Подменить T в тесте нельзя: тип фиксируется на этапе компиляции. Границы с внешним миром должны быть интерфейсами.
• Одна-две инстанциации. Дженерик ради двух типов крадёт читаемость, добавляет к размеру бинаря и ничего не даёт. Две функции честнее.
• Union из «всех типов, которые я знаю». Такой констрейнт нельзя расширить снаружи пакета: каждый новый тип означает правку библиотеки. Анти-паттерн, если только множество действительно не замкнуто (например, числовые типы).
• Кодогенерация вместо дизайна. Если сигнатура выглядит как func Do[A, B, C any, F ~func(A) (B, error)](...), читать это будет невозможно, и через полгода перепишут в первую очередь именно её.

Когда дженерики - явно правильный выбор

• Контейнеры и структуры данных: Set[T], Queue[T], OrderedMap[K,V], LRU-кэш, лок-фри очередь.
• Алгоритмы над коллекциями: slices, maps, group-by, chunk, partition.
• Инфраструктурные обёртки: Pool[T] (типобезопасный sync.Pool), Result[T], Optional[T], singleflight с типом.
• Конкурентные примитивы: Fanout[T], типизированный errgroup-воркер, батчер.
• Устранение зеркальных пакетов: там, где раньше писали strings и bytes отдельно.

// Пример, где дженерик даёт настоящую пользу: типобезопасный sync.Pool.
// Без него на каждом Get стоит .(*Buffer), а такой assertion может паниковать.
type Pool[T any] struct {
    p   sync.Pool
    new func() T
}

func NewPool[T any](new func() T) *Pool[T] {
    return &Pool[T]{p: sync.Pool{New: func() any { return new() }}, new: new}
}
func (p *Pool[T]) Get() T   { return p.p.Get().(T) }   // assertion спрятана внутри, наружу - T
func (p *Pool[T]) Put(v T)  { p.p.Put(v) }

// Пример, где дженерик - ошибка: «универсальный репозиторий»
type Repo[T any] interface {
    Get(ctx context.Context, id int64) (T, error)
    Save(ctx context.Context, v T) error
}
// Дальше понадобится ListActive, FindByEmail, UpdateBalance - и абстракция рассыпается.
// Плюс имя таблицы всё равно берут рефлексией или из отдельного метода, так что
// типобезопасность, ради которой всё затевалось, теряется в самом важном месте.

Как это работает под капотом: GC shape stenciling

Классических способов реализовать дженерики ровно два, и оба чего-то стоят. Мономорфизация (C++ templates, Rust): компилятор генерирует отдельную копию машинного кода под каждый набор типов. Скорость максимальная, зато бинарь и время сборки растут взрывом. Стирание типов (Java generics, Go до 1.18 через interface{}): один код, все значения приводятся к общему представлению. Бинарь маленький, зато боксинг, аллокации и косвенные вызовы.

Go выбрал гибрид, «GC shape stenciling». Слово stencil переводится как трафарет: компилятор берёт тело дженерик-функции и «печатает» по нему готовую копию машинного кода; такую копию и называют стенсилом. Печатает он их не по одной на каждый тип, а по одной на каждую GC-форму, то есть на каждую группу типов, которые по размеру и раскладке указателей внутри выглядят для сборщика мусора одинаково. Всё, что у типов из одной группы всё-таки разное (описание типа, адреса методов, itab), передаётся отдельно, скрытым первым аргументом, который называют словарём. Правило группировки из design-документа звучит буквально так:

Что лежит в словаре

Словарём зовут статическую структуру, которую компилятор кладёт в read-only секцию бинаря (по одной на каждую конкретную инстанциацию, не на форму) и передаёт скрытым первым аргументом. Внутри лежит всё, чего стенсил знать не может: он один на много типов.

Пакеты slices и maps

Главный продукт дженериков для повседневного кода. Оба пакета переехали из golang.org/x/exp в стандартную библиотеку в Go 1.21, вместе с пакетом cmp (там живёт cmp.Ordered, cmp.Compare, cmp.Or). В Go 1.23 оба пакета получили вторую волну функций, уже на итераторах.

import ("slices"; "maps"; "cmp")

// ── slices: поиск и сортировка ──────────────────────────────────────
xs := []int{5, 2, 9, 2}

slices.Sort(xs)                       // [2 2 5 9] - pdqsort, без рефлексии
slices.SortStableFunc(users, func(a, b User) int {
    return cmp.Compare(a.Age, b.Age)  // компаратор возвращает -1/0/+1, а не bool
})
i, found := slices.BinarySearch(xs, 5)          // 2, true - только на отсортированном
idx := slices.Index(xs, 9)                      // 3, или -1
ok  := slices.Contains(xs, 2)                   // true
j   := slices.IndexFunc(users, func(u User) bool { return u.Admin })

// ── slices: сравнение и модификация ─────────────────────────────────
slices.Equal([]int{1,2}, []int{1,2})            // true - поэлементно, без reflect
slices.Compare(a, b)                            // лексикографически: -1/0/+1
xs = slices.Compact(xs)                         // убирает подряд идущие дубли: [2 5 9]
xs = slices.Insert(xs, 1, 7, 8)                 // вставляет несколько по индексу
xs = slices.Delete(xs, 1, 3)                    // удаляет полуинтервал [1:3)
slices.Reverse(xs)
c := slices.Clone(xs)                           // поверхностная копия
m := slices.Max(xs)                             // паникует на пустом слайсе
g := slices.Grow(xs, 100)                       // гарантирует cap для 100 доп. элементов
xs = slices.Clip(xs)                            // cap = len: append больше не пишет в общий хвост; массив тот же

// ── maps ────────────────────────────────────────────────────────────
mm := map[string]int{"a": 1, "b": 2}
maps.Clone(mm)                                  // поверхностная копия
maps.Equal(mm, other)                           // сравнивает по значениям
maps.Copy(dst, src)                             // src поверх dst
maps.DeleteFunc(mm, func(k string, v int) bool { return v == 0 })

// ── Go 1.23: итераторы (iter.Seq) ───────────────────────────────────
for k := range maps.Keys(mm) { _ = k }          // maps.Keys теперь возвращает итератор
keys := slices.Sorted(maps.Keys(mm))            // []string{"a","b"} - идиома «ключи по порядку»
for i, v := range slices.All(xs) { _, _ = i, v }
for v := range slices.Values(xs) { _ = v }
back := slices.Backward(xs)                     // итератор в обратном порядке
xs2  := slices.Collect(maps.Values(mm))         // итератор → слайс

Go 1.26 и 1.27: что в дженериках изменилось

Go 1.27: у методов появились собственные параметры типа

Годами правильным ответом на собесе было «параметр типа у метода объявить нельзя, выноси в свободную функцию». С Go 1.27 это неверно. Метод обычного или дженерик-типа теперь объявляет свои параметры типа ровно так же, как функция:

type Box struct {
    v []int
}

// Go 1.27: метод объявляет собственный параметр типа T
func (b *Box) MapTo[T any](f func(int) T) []T {
    out := make([]T, 0, len(b.v))
    for _, x := range b.v { out = append(out, f(x)) }
    return out
}

b := &Box{v: []int{1, 2, 3}}
fmt.Println(b.MapTo(func(i int) string { return strconv.Itoa(i * 2) }))  // [2 4 6]

// Работает и для дженерик-типа: получатель перечисляет свои параметры, метод добавляет свои
type Stack[T any] struct {
    items []T
}
func (s *Stack[T]) MapTo[R any](f func(T) R) *Stack[R] {
    out := &Stack[R]{items: make([]R, 0, len(s.items))}
    for _, v := range s.items { out.items = append(out.items, f(v)) }
    return out
}

Пример из стандартной библиотеки есть в math/rand/v2: метод Rand.N() стал дженерик-методом, поэтому r.N(100) возвращает int, а r.N(time.Second) уже time.Duration, без конверсий на месте вызова.

type Mapper interface {
    MapTo[T any](f func(int) T) []T   // ошибка: interface method must have no type parameters
}

Go 1.26: дженерик-тип может ссылаться на себя в собственном констрейнте

Раньше компилятор отвергал «self-referential» констрейнт, когда параметр типа ограничен интерфейсом, параметризованным этим же параметром. С Go 1.26 это легально, и привычный по другим языкам паттерн «тип, который умеет складываться сам с собой» наконец выражается прямо:

// Go 1.26+
type Adder[A Adder[A]] interface{ Add(A) A }

type Num int
func (n Num) Add(o Num) Num { return n + o }

func Sum[A Adder[A]](xs []A) A {
    var acc A
    for _, x := range xs { acc = acc.Add(x) }
    return acc
}
fmt.Println(Sum([]Num{1, 2, 3}))   // 6

Читается это так: «A может быть любым типом, у которого есть метод Add, принимающий и возвращающий этот же самый A». Без самоссылки такой контракт выражался только через any и рантайм-проверки.

Go 1.26: new принимает выражение

Не про дженерики, но про тот же класс неудобств. Раньше new принимал только тип, и чтобы получить указатель на результат выражения, приходилось заводить временную переменную ради &tmp. Теперь можно передать само выражение:

// До 1.26
tmp := compute()
p := &tmp

// Go 1.26+
p := new(compute())     // *T, где T - тип результата compute()

// Особенно заметно на литералах и константах, у которых нельзя взять адрес напрямую:
q := new(42)            // *int
r := new(len(s) * 2)    // *int

Применяют это в опциональных полях структур (Field *int) и в параметрах клиентов облачных API, где половина кода раньше состояла из вызовов самописного помощника func ptr[T any](v T) *T. Такой помощник теперь не нужен.

Go 1.27: вывод типов стал общее

Раньше вывод типов работал главным образом в точке вызова: из аргументов. В 1.27 он обобщён на все контексты, где дженерик-функция присваивается переменной или конвертируется в совместимый тип функции. Практически это значит, что в таких местах реже приходится писать аргументы типа руками: компилятор берёт их из типа приёмника.

Чего дженерики в Go не умеют - и почему

Список ограничений сознательный: каждое из них выкинуто, чтобы не получить систему типов, которую невозможно ни быстро скомпилировать, ни объяснить.

// Обход №1 (нужен только до Go 1.27 либо когда метод обязан жить в интерфейсе)
type Stack[T any] struct {
    items []T
}

// func (s *Stack[T]) Map[R any](f func(T) R) *Stack[R]   // до 1.27 не компилировалось,
//                                                        // с 1.27 вполне легально
func MapStack[T, R any](s *Stack[T], f func(T) R) *Stack[R] {
    out := &Stack[R]{items: make([]R, 0, len(s.items))}
    for _, v := range s.items { out.items = append(out.items, f(v)) }
    return out
}

// Обход №2: «специализация» руками, через type switch по any(v)
func Format[T any](v T) string {
    switch x := any(v).(type) {          // конверсия any(v) обязательна
    case time.Time:  return x.Format(time.RFC3339)
    case error:      return x.Error()
    case fmt.Stringer: return x.String()
    default:         return fmt.Sprint(v)
    }
}
// Цена: это рантайм-проверка. Если такой switch занимает всё тело, дженерик тут лишний:
// достаточно обычного func Format(v any) string.

// Обход №3: инвариантность - почему это не баг
type List[T any] struct {
    xs []T
}
var dogs List[*Dog]
// var animals List[*Animal] = dogs      // ошибка, и правильно:
// иначе через animals.Append(&Cat{}) в dogs попал бы кот.

// Функция
func Keys[K comparable, V any](m map[K]V) []K {
    out := make([]K, 0, len(m))
    for k := range m { out = append(out, k) }
    return out
}

// Тип + методы: получатель перечисляет параметры типа, но не вводит новые
type Set[T comparable] struct{ m map[T]struct{} }

func NewSet[T comparable](vs ...T) *Set[T] {
    s := &Set[T]{m: make(map[T]struct{}, len(vs))}
    for _, v := range vs { s.m[v] = struct{}{} }
    return s
}
func (s *Set[T]) Add(v T)          { s.m[v] = struct{}{} }
func (s *Set[T]) Has(v T) bool     { _, ok := s.m[v]; return ok }
func (s *Set[T]) Len() int         { return len(s.m) }

// Нулевое значение параметра типа - через var, *new(T) или именованный результат
func (s *Set[T]) Any() (T, bool) {
    for v := range s.m { return v, true }
    var zero T                       // не nil и не 0, а var zero T
    return zero, false
}

type Number interface{ ~int | ~int64 | ~float64 }

func Sum[T Number](xs []T) T {
    var s T
    for _, x := range xs { s += x }   // + разрешён: он есть у всех типов множества
    return s
}

// А вот так уже нельзя:
type Weird interface{ ~int | ~string }
func Bad[T Weird](a, b T) T {
    return a - b       // ошибка: оператор - не определён для string
    // при этом a + b сработало бы: + есть и у чисел, и у строк
}

type Celsius float64

func SumStrict[T interface{ float64 }](xs []T) T { ... }
func SumLoose [T interface{ ~float64 }](xs []T) T { ... }

temps := []Celsius{36.6, 37.1}
// SumStrict(temps)   // ошибка: Celsius does not satisfy interface{float64}
//                    //         (possibly missing ~ for float64)
SumLoose(temps)       // ок

// Ограничение самой тильды: справа обязан стоять тип, чей underlying - он сам
// interface{ ~Celsius }   // ошибка: invalid use of ~ (underlying type of Celsius is float64)
// Поэтому нельзя написать «любой тип, производный от Celsius».

func Count[T comparable](s []T) map[T]int {
    m := make(map[T]int, len(s))
    for _, v := range s { m[v]++ }
    return m
}

Count([]string{"a", "a"})                 // ок
Count([][3]int{{1,2,3}})                  // ок - массив из int
// Count([][]int{{1}})                     // ошибка компиляции: []int does not satisfy comparable

// Go 1.20+: это компилируется...
vals := []any{1, "x", []int{1, 2}}
Count(vals)                               // ...и паникует в рантайме:
// panic: runtime error: hash of unhashable type []int

// x/exp/constraints целиком, тут нечего скрывать
type Signed   interface{ ~int | ~int8 | ~int16 | ~int32 | ~int64 }
type Unsigned interface{ ~uint | ~uint8 | ~uint16 | ~uint32 | ~uint64 | ~uintptr }
type Integer  interface{ Signed | Unsigned }
type Float    interface{ ~float32 | ~float64 }
type Complex  interface{ ~complex64 | ~complex128 }
type Ordered  interface{ Integer | Float | ~string }

// В stdlib (Go 1.21) есть пакет cmp:
//   type cmp.Ordered - то же множество
//   func cmp.Compare[T Ordered](x, y T) int   // -1 / 0 / +1
//   func cmp.Less[T Ordered](x, y T) bool
//   func cmp.Or[T comparable](vals ...T) T    // Go 1.22: первое ненулевое

// 1) только методы: обычный интерфейс, годится и как тип
type Named interface{ Name() string }

// 2) только типы
type Numeric interface{ ~int | ~int64 | ~float64 }

// 3) пересечение: и underlying, и метод
type Code interface {
    ~int                 // underlying обязан быть int
    String() string      // и обязан быть метод String
}
type HTTPStatus int
func (s HTTPStatus) String() string { return http.StatusText(int(s)) }
// HTTPStatus удовлетворяет Code

// 4) композиция констрейнтов
type SignedNumeric interface{ constraints.Signed | Float }

type Setter[T any] interface {
    *T                      // PT обязан быть именно *T
    SetDefaults()           // и иметь этот метод (он с pointer receiver)
}

func Build[T any, PT Setter[T]](n int) []T {
    out := make([]T, n)
    for i := range out {
        PT(&out[i]).SetDefaults()   // &out[i] имеет тип *T, конвертируем в PT
    }
    return out
}

type Config struct {
    Timeout time.Duration
}
func (c *Config) SetDefaults() { c.Timeout = 30 * time.Second }

cfgs := Build[Config](3)      // PT = *Config выводится из T автоматически

// ── Работает ─────────────────────────────────────────────
slices.Sort(ids)                       // S из аргумента, E из констрейнта
Keys(m)                                // K, V из типа мапы
Build[Config](3)                       // PT выведен из T

// ── Не работает ──────────────────────────────────────────
func Zero[T any]() T          { var z T; return z }
// z := Zero()                          // cannot infer T - параметр только в результате
z := Zero[int]()

func New[T any]() *T          { return new(T) }
// p := New()                           // то же самое
p := New[Repo]()

var f = Map                             // cannot use generic function Map without instantiation
var g = Map[int, string]                // так - ок

// Литерал функции без типов параметров:
// Reduce(xs, 0, func(a, e) int { return a + e })   // не скомпилируется: у литерала функции типы параметров обязательны
Reduce(xs, 0, func(a, e int) int { return a + e })  // ок

// untyped nil:
// Ptr(nil)                             // cannot infer T
Ptr[*User](nil)

// Показательная пара. Дженерик - там, где меняется тип:
func GroupBy[T any, K comparable](s []T, key func(T) K) map[K][]T {
    m := make(map[K][]T)
    for _, v := range s { m[key(v)] = append(m[key(v)], v) }
    return m
}

// Интерфейс - там, где меняется поведение:
type Notifier interface{ Notify(ctx context.Context, msg string) error }
type Email struct {
    ...
}   // своя реализация
type SMS struct {
    ...
}   // своя реализация
func Broadcast(ctx context.Context, ns []Notifier, msg string) { ... }
// Сделать это дженериком нельзя: []Notifier гетерогенен по определению.

type UserID int
type Age    int

// Index[int], Index[UserID], Index[Age]  → один стенсил (underlying = int)
// Index[int64]                           → отдельный стенсил (другой underlying)
// Index[*User], Index[*Order], Index[*T] → один стенсил (все указатели)
// Index[string]                          → отдельный
// Index[struct{ A int }]                 → отдельный

// В pprof и в дизассемблере это выглядит так:
//   main.Index[go.shape.int_0]
//   main.Index[go.shape.*uint8_0]

// Концептуально компилятор превращает
func Index[T comparable](s []T, v T) int { ... }
// в нечто вроде
func Index_shape_int(dict *dictionary, s []shapeInt, v shapeInt) int { ... }
// и на каждом вызове подставляет нужный словарь:
//   Index_shape_int(&dict_Index_int,    ints, 5)
//   Index_shape_int(&dict_Index_UserID, ids,  UserID(5))

// Бенчмарк, который стоит уметь написать на доске
type Num interface{ ~int64 }

func SumConcrete(xs []int64) int64            { var s int64; for _, x := range xs { s += x }; return s }
func SumGeneric[T Num](xs []T) T              { var s T;     for _, x := range xs { s += x }; return s }
func SumIface(xs []any) int64 {
    var s int64
    for _, x := range xs { s += x.(int64) }   // плюс аллокации при создании []any
    return s
}

func BenchmarkSum(b *testing.B) {
    xs := make([]int64, 1_000)
    b.Run("concrete", func(b *testing.B) { for b.Loop() { _ = SumConcrete(xs) } })
    b.Run("generic",  func(b *testing.B) { for b.Loop() { _ = SumGeneric(xs)  } })
    ys := make([]any, len(xs))
    for i, x := range xs { ys[i] = x }
    b.Run("iface",    func(b *testing.B) { for b.Loop() { _ = SumIface(ys)    } })
}
// Типичный результат: concrete ≈ generic (разница в пределах шума),
// iface в разы хуже, и это ещё без учёта аллокаций на упаковку.

// Компаратор сменил форму: частая ошибка при миграции
sort.Slice(us, func(i, j int) bool { return us[i].Age < us[j].Age })    // bool, по индексам
slices.SortFunc(us, func(a, b User) int { return cmp.Compare(a.Age, b.Age) })  // int, по значениям

// Сортировка по нескольким полям читается лучше через cmp.Or (Go 1.22)
slices.SortFunc(us, func(a, b User) int {
    return cmp.Or(
        cmp.Compare(a.LastName, b.LastName),
        cmp.Compare(a.FirstName, b.FirstName),
        cmp.Compare(a.Age, b.Age),
    )
})

// slices.Sort не стабилен (pdqsort). Для стабильности есть SortStableFunc.
// Детерминированный обход мапы:
for _, k := range slices.Sorted(maps.Keys(m)) {   // 1.23: maps.Keys - итератор
    fmt.Println(k, m[k])
}
// ключи идут по возрастанию при любом запуске, в отличие от голого range по мапе

type Stack[T any] struct {
    items []T
}

// Go 1.27: легально
func (s *Stack[T]) MapTo[R any](f func(T) R) *Stack[R] {
    out := &Stack[R]{items: make([]R, 0, len(s.items))}
    for _, v := range s.items { out.items = append(out.items, f(v)) }
    return out
}

// А вот это по-прежнему ошибка: interface method must have no type parameters
type Mapper[T any] interface {
    MapTo[R any](f func(T) R) *Stack[R]
}

// Так нельзя (C++ template specialization):
// func Print[T any](v T)      { fmt.Println(v) }
// func Print[T string](v T)   { fmt.Println("str:", v) }
// ошибка компиляции: Print redeclared in this block
//                    other declaration of Print

// Так можно, но это рантайм-проверка:
func Print[T any](v T) {
    if s, ok := any(v).(fmt.Stringer); ok { fmt.Println(s.String()); return }
    fmt.Println(v)
}

Print(42)                // 42
Print("hi")              // hi
Print(90 * time.Second)  // 1m30s - у time.Duration есть String(), сработала первая ветка

type Animal interface{ Sound() string }
type Dog struct{}
func (Dog) Sound() string { return "woof" }

var dogs []Dog
// var animals []Animal = dogs    // ошибка: cannot use dogs ([]Dog) as []Animal

type Box[T any] struct {
    v T
}
var bd Box[Dog]
// var ba Box[Animal] = bd        // ошибка: Box[Dog] и Box[Animal] - разные типы

Что стоит запомнить

• Constraint задаёт множество допустимых типов.
• Дженерик сохраняет связь типов входа и результата.
• Интерфейс задаёт runtime-поведение.

Частые ошибки

• Не добавляй параметр типа без типовой пользы.
• Вывод типа ограничен контекстом.

func same[T comparable](a, b T) bool { return a == b }
fmt.Println(same(2, 2), same("a", "b"))

func min[T any](a, b T) T {
  if a < b { return a }; return b
}