Дженерики: обобщённые функции и типы

К марту 2022 года Go был единственным крупным языком без обобщённого программирования: с версии 1.0 по 1.17 язык прожил без дженериков, и сообщество писало генераторы кода, копии функций и коробки any. Версия 1.18 привнесла type parameters — параметры типов — и это самое большое расширение языка за всю его историю. В англоязычной документации тема называется generics (запрос generics golang — он и приводит на эту страницу), по-русски говорят «обобщённые функции», «параметризованные типы», «тип-параметры». Всё это об одном: одна функция или один тип — и список типов, с которыми он работает.

У нас уже есть три инструмента для лозунга «одна функция — много типов», и каждый платит свою цену. Интерфейсы дал десятый урок, коробку any — одиннадцатый, инструменты распаковки — двенадцатый. Интерфейсы дают полиморфизм поведения: любой тип с нужными методами подходит, но тело функции видит только методы контракта. any — контракт без единого метода: положить можно всё, работать с содержимым — ничего. Type assertion — распаковка коробки: проверка динамического типа уходит в рантайм, а ошибка стоит паники interface conversion или флага ok. Дженерики — четвёртый инструмент, и их цена другая: проверка возвращается компилятору. Тип-параметр T живёт в сигнатуре, конкретный тип подставляется при вызове, и ни пары «динамический тип + значение», ни утверждения, ни рантайм-проверки не нужно.

План урока: сначала боль, которую лечат дженерики, — три копии одной функции; затем анатомия type parameters и первый обобщённый Max; вывод типов — почему Max(1, 2) собирается без [int]; констрейнты any, comparable и union; cmp.Ordered и судьба знаменитого пакета constraints; обобщённые типы на примере Stack[T]; и развилка, на которой дженерики не нужны вовсе. Все интерактивы урока исполняются основным движком песочницы (настоящий yaegi) и локальным go run; первый раннер работает в обоих движках, остальные — только в основном, и почему — честно разобрано в плашке перед финалом.

Сформулируем задачу так, как её формулировали каждый день до версии 1.18. Нужна функция «большее из двух» — для целых, для строк, для дробных. Дженериков нет, интерфейсы не помогают: у int нет методов, контракт «умеет сравниваться» в Go не существовал, а any внутри — это коробка, из которой арифметику не достать (одиннадцатый урок показал это на box[0] + 1, который не собирается). Оставалось два честных пути.

Путь первый — копии. maxInt(a, b int), maxString(a, b string), maxFloat64(a, b float64) — три функции с идентичными телами, отличающиеся только типами в подписи. Тело маленькое — потеря терпима; но представьте не три строки, а сорок: сорок копий сорок раз правятся при каждой ошибке, и компилятор не напомнит, что вы забыли одну.

Путь второй — any + assertion. Одна функция maxAny(a, b any) any: внутри ok-формы «вы это int?», «вы это string?» — каскад утверждений из двенадцатого урока, при неудаче — паника или флаг. Цена: проверка уходит в рантайм, а возвращённое значение — снова any, и вызывающему распаковывать его ещё раз. Ошибка «передали не тот тип», которую компилятор ловит на обычных функциях мгновенно, у maxAny обнаружится в три часа ночи на проде.

Оба пути платят за одну и ту же вещь: отсутствие типа в сигнатуре. Копии платят дублированием, any — безопасностью. Дженерики снимают плату целиком: тип остаётся неизвестным на момент написания функции, но известным — и проверенным — на момент вызова. Раннер ниже показывает первый путь: запустите его, посмотрите на три идентичных тела, а дальше урок напишет то же самое одной функцией.

Вот та же функция, написанная один раз:

func Max[T cmp.Ordered](a, b T) T { if a > b { return a }; return b }

Читаем подпись по членам, слева направо. Имя — Max. Затем квадратные скобки [T cmp.Ordered] — список тип-параметров; это новая секция синтаксиса, которой до 1.18 не было. Внутри: T — имя тип-параметра (традиция: одна буква, как у переменной цикла; в больших сигнатурах встречаются T, R, K, V — тип и результат, ключ и значение). cmp.Ordered — констрейнт, контракт тип-параметра: «T — какой-нибудь тип, который умеет сравниваться знаками < и >». Затем обычные круглые скобки: параметры a, b T — оба выражены через тип-параметр, то есть их тип станет известен при вызове. Последнее T — тип результата, тоже параметризованный.

Ключевое отличие от any — где живёт неизвестность. В func maxAny(a, b any) any неизвестность уже внутри: любые операции над a, кроме самых общих, не скомпилируются, а возвращённая коробка требует распаковки. В func Max[T cmp.Ordered](a, b T) T неизвестность — в подписи, и она ограничена контрактом: тело вправе применять к a и b всё, что обещает cmp.Ordered, — сравнение, равенство — и ни одной операции сверх. При вызове Max(3, 7) компилятор подставит конкретный тип (int), соберёт отдельную версию функции и проверит тело уже с ним: ошибка «строку сравнили знаком больше, а строки так не умеют» — у народа, который обещает только равенство, — будет найдена на этапе сборки, а не в рантайме.

Процесс подстановки конкретного типа вместо T называется инстанциацией. Она бывает неявной — компилятор сам выводит тип из аргументов (вывод типов, ниже) — и явной: Max[int](3, 7). Квадратные скобки на месте вызова — это вы, а не компилятор, называете тип; они же спасают, когда вывод неоднозначен.

В первом раннере мы вызвали Max(3, 7) — и нигде не написали int. Это вывод типов (type inference): компилятор смотрит на типы аргументов, сопоставляет их с тип-параметрами сигнатуры и сам решает, что T — int. Механика называется унификацией: аргументы int и int, параметр T — значит T = int; одна переменная выводится из всех своих использований сразу, и они обязаны согласиться. Max(3, 7) — T = int; Max("кот", "кит") — T = string; Max(1, "x") — вывод не согласован, ошибка компиляции: один T не может быть одновременно int и string, приводить типы за вас компилятор не станет.

Правило курса: пишите вызов без скобок, пока вывод справляется. Явная инстанциация Max[int](3, 7) нужна в трёх случаях. Первый — вывод невозможен: тип не встречается в аргументах (результатный R у func Pair[T, R any](a T, b R) выводится из b — а вот если R встречается только в результате, его придётся назвать). Второй — аргументы — нетипизированные константы и вывод спорит: с union-констрейнтом ниже вы увидите это вживую. Третий — вы хотите сами назвать тип ради читателя или ради цепочки вызовов, где дальше важен конкретный тип.

И честная нота про песочницу, проверенная пробником до написания урока. Основной движок (yaegi) выводит целые нетипизированные константы нормально: Max(3, 7) работает. А вот дробные нетипизированные константы он не выводит: Max(2.5, 1.5) отвечает «untyped float does not implement cmp.Ordered», хотя настоящий Go спокойно выводит T = float64. Обхода два — типизированная переменная (fx, fy := 2.5, 1.5, затем Max(fx, fy)) или явная инстанциация Max[float64](2.5, 1.5). Локальный go run выводит дробные константы честно — это ограничение именно песочницы, и оно разобрано в плашке урока.

Констрейнт — это обещание о тип-параметре, записанное в сигнатуре. Тело функции вправе применять к значениям T ровно те операции, которые обещает констрейнт, — и ни одной больше. Компилятор проверяет тело против констрейнта один раз (при сборке функции), а каждый вызов — против констрейнта же (подходит ли конкретный тип обещанию). Это двусторонний договор: и телу, и вызывающему известно одно и то же.

Минимальный констрейнт — any: func Dup[T any](v T) (T, T) — «T — какой-нибудь тип, обещаний нет». Внутри такой функции над значениями T нельзя ни сравнивать, ни складывать, ни упорядочивать — можно хранить, передавать, возвращать, брать var zero T (нулевое значение неизвестного типа — int даст 0, string — пустую строку). any-дженерик полезен для контейнеров и обёрток: пара (T, T) из Dup, срезы, стеки. Как только телу нужна операция — поднимайте контракт.

Констрейнт comparable обещает равенство: значения типа T можно сравнивать знаками == и !=. Это встроенный контракт, и он точен до синтаксиса: под обещание подходят все сравнимые типы — числа, строки, булевы, указатели, каналы, интерфейсы, а также структуры и массивы, все поля и элементы которых сравнимы. Срезы, карты и функции сравнимыми не являются. Зачем это нужно? Вся арифметика проверки существования: func Contains[T comparable](s []T, v T) bool — линейный поиск, func Equal[T comparable](a, b T) bool, ключи карт map[T]int — тип-параметр ключа обязан быть comparable, потому что карта сравнивает ключи. Напомним язык двенадцатого урока: assertion спрашивал «ты int?» в рантайме и платил паникой; comparable обещает «ты умеешь ==» на этапе компиляции — вопрос снят до запуска.

Важно, чего comparable НЕ обещает: порядка. a < b над T с контрактом comparable не скомпилируется — обещание «равенство» не покрывает «меньше-больше». Для порядка нужен контракт со сравнением — cmp.Ordered или union, о них ниже. Правило выбора простое: берите минимальный констрейнт, достаточный телу — чем меньше обещаний, тем больше типов сможет вызвать функцию.

Union — констрейнт, записанный перечислением типов через вертикальную черту. Синтаксис нарочно использует слово interface: type Number interface { int | float64 }. Это интерфейс нового образца — не контракт поведения, а множество типов: у него нет ни одного метода, его нельзя «реализовать», в него входят ровно перечисленные типы. Тело func Sum[T Number](a, b T) T вправе делать с a и b то, что умеют ОБА типа множества: сложение, вычитание, сравнение; делить на строку — не вправе, строки в множестве нет. Косая черта читается «или», а унификация вывода работает так же, как раньше: Sum(2, 3) — int, Sum(fx, fy) с типизированными float64 — float64.

Нюанс, который стоит знать с самого начала: int | float64 — это ровно эти два типа, и named-типы поверх них (type Celsius float64) в множество не входят. Чтобы включить «все типы, чьим базовым является float64», пишут волну: ~float64. В наших примерах достаточно голых имён, но в библиотечном коде встретите тильду постоянно.

Теперь три пути к констрейнту «упорядоченный» — история, в которой запутаться легче всего, поэтому распутываем здесь. Путь первый — самодельный union: type Ordered interface { int | float64 | string } — вы перечисляете типы вручную; в песочнице это работает, но список длинный (в Ordered входят все целые и дробные размеры). Путь второй — cmp.Ordered: с версии Go 1.21 в стандартной библиотеке живёт пакет cmp, и его констрейнт cmp.Ordered обещает ровно нужное — все целые, все дробные и строки, то есть <, >, == и company. Наш раннер с Max использует именно его, и песочница его импортирует без проблем — проверено пробником. Путь третий — golang.org/x/exp/constraints: знаменитый внешний пакет, с которого всё началось до 1.21; constraints.Ordered из него и был образцом для stdlib. В песочнице этот пакет импортировать нельзя — основной движок отвечает «unable to find source related to: golang.org/x/exp/constraints» (проверено пробником до написания урока): внешний модуль в песочницу не установлен. Локально он работает после go get golang.org/x/exp, но новому коду рекомендуют stdlib-версию — cmp.Ordered. В тексте и комментариях урока слово constraints остаётся общим термином для «контракта тип-параметра», а конкретные констрейнты мы пишем самодельным union-ом или cmp.Ordered.

Type parameters живут не только у функций — у типов тоже. type Stack[T any] struct { items []T } объявляет обобщённый стек: T — тип-параметр на уровне всего типа, и внутри объявления срез items хранит элементы именно T. Это то, чего any дать не мог в принципе: Stack{ items: []any{...} } — коробка, в которую кладётся что угодно и из которой ничего не достаётся без assertion; Stack[string] — конкретный тип, куда int не положит компилятор, а не рантайм.

Методы обобщённого типа получают приёмник с тем же параметром: func (s *Stack[T]) Push(v T) — читается «метод Push у Stack с элементами T». Обратите внимание: внутри приёмника и сигнатуры метода T уже не объявляется — он объявлен у типа, и методы лишь используют его. Указательный приёмник здесь не прихоть: Push меняет стек на месте, добавляя в срез items.

Инстанциация — та же, что у функций: Stack[string]{} — композитный литерал уже конкретного типа; var s Stack[int] — нулевой стек для int. Два инстанцирования — два разных типа: Stack[int] и Stack[string] не присваиваются друг другу, хотя написаны одной декларацией. Это цена и сила: одна логика — и полная типовая дисциплина внутри каждой версии.

Внутри метода встретится приём, достойный отдельного абзаца: var zero T — нулевое значение неизвестного типа. Pop на пустом стеке обязан вернуть «ничего», но какого типа? Типа T — и var zero T даёт ровно его: для int это 0, для string — "", для указателя — nil. Без any-коробки, без утверждения, без паники: язык сам знает нулевое значение каждого типа, который подставится. Второе значение ok в паре Pop() (T, bool) — та же идиома «комма-ок», что у чтения канала и type assertion: результат и флаг честности рядом.

Дженерики — самый громкий инструмент языка, и громкость провоцирует злоупотребление: как только они появились, код начал обрастать [T any] там, где нужен был обычный int. Четыре случая, когда дженерики не нужны — и что писать вместо них.

Случай первый: тип на самом деле один. Если функция работает только с int — напишите её с int. func maxInt(a, b int) int короче, читается мгновенно, и вывод типов не нужен никому. Обобщение ради обобщения добавляет квадратные скобки в каждую подпись и третий вопрос к каждому читателю («а что тут может быть?»). Правило: пишите конкретный тип, пока конкретный тип справляется; дженерик — когда появился ВТОРОЙ тип с той же логикой.

Случай второй: различается поведение, а не тип. Если «разные типы» на самом деле означают «разные действия» — это территория интерфейсов из одиннадцатого урока: контракт поведения, duck typing, полиморфизм методов. fmt.Stringer, io.Reader, error — интерфейсы, и дженерики их не заменяют: generic-функция делает ОДНО и то же с разными типами, интерфейсная — РАЗНОЕ с одним контрактом.

Случай третий: данные по-настоящему разнородны. Коробка []any из одиннадцатого урока и type switch из двенадцатого остаются правильным инструментом там, где типы элементов неизвестны ВООБЩЕ — парсинг JSON, плагины, обработчики с внешним контрактом. Дженерик требует, чтобы тип был известен на момент вызова; если не известен — дженерик не про это.

Случай четвёртый: хватает any. func Dup[T any](v T) (T, T) честнее написать func Dup(v any) (any, any), если вызывающему всё равно придётся распаковывать: тип-параметр без операций в теле и без использования связей (a и b одного T) — это any с лишними скобками. Дженерик становится сильнее any, когда T встречается в сигнатуре ДВАЖДЫ и больше — «вернёт тот же тип, что принял», «примет срез из T, вернёт T» — связь, которую any не выражает никогда. Стандартная библиотека до сих пор наполовину не-дженерик: fmt.Println принимает any, а slices.Contains и slices.Sort — дженерики; каждый инструмент на своём месте.

Виток «одна функция — много типов» закрыт полностью. Одиннадцатый урок собрал коробку any, двенадцатый научил её распаковывать — ok-формой, одиночной формой и type switch, — а сегодняшний сделал так, чтобы распаковка была не нужна: тип живёт в сигнатуре, констрейнт обещает операции, компилятор проверяет и тело, и вызовы. Три ответа языка на одну боль — any, assertion, дженерики — теперь у вас все; выбираются они так: поведение — интерфейсы, разнородные данные — any и type switch, одинаковая логика на разных типах — type parameters.

Что дальше? Четырнадцатый урок — пакеты и модули: как код раскладывается по файлам и каталогам, что экспортирует заглавная буква, как работает go mod, зачем внутренние пакеты и как приходят версии. До сих пор все наши программы были одним файлом main.go — пора понять, из чего собирается настоящий проект, и заодно выяснить, почему golang.org/x/exp/constraints из сегодняшнего урока в песочнице не импортируется: у внешних модулей есть собственная дисциплина подключения. Дальше по курсу — ошибки со сквозной упаковкой (errors.Is и errors.As, куда вырастет err.(*MyErr) из двенадцатого урока). Весь список тем — на странице курса.