Дженерики в Go

Параметр типа и вывод

Параметры типа пишутся в квадратных скобках после имени функции: func Sum[T Number](xs []T) T. Внутри T ведёт себя как обычный тип, а при вызове компилятор чаще всего выводит его сам из аргументов - явные скобки при вызове почти никогда не нужны.

Проверено: Sum([]int{1,2,3}) возвращает 6, вызов записан без указания типа. Функция Map с двумя параметрами типа тоже выводится: Map([]int{1,2}, func(i int) string {...}) отдаёт []string, и типы на входе и выходе разные.

Ключевое отличие от any: типизация сохраняется насквозь. Функция принимает []T и возвращает T, а не any, поэтому у вызывающего результат уже нужного типа, без утверждений и без риска паники.

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

type Number interface{ ~int | ~float64 }

func Sum[T Number](xs []T) T {
    var total T
    for _, x := range xs { total += x }
    return total
}

Sum([]int{1, 2, 3})   // 6, тип выведен, скобки не нужны

Ограничения и тильда

Ограничение - это интерфейс, но в новой роли: кроме методов он описывает допустимые базовые типы. interface{ ~int | ~float64 } читается как «любой тип, чья основа - int или float64».

Тильда здесь принципиальна. Без неё ограничение int | float64 пропускает только сами эти типы. С тильдой проходят и производные: type Celsius float64 удовлетворяет ~float64. Проверено: Sum по срезу Celsius считается и возвращает 4 при слагаемых 1,5 и 2,5.

Без тильды такая функция отказалась бы работать с любым доменным типом на базе числа - а их в нормальном коде много. Поэтому в стандартных ограничениях из пакета constraints тильда стоит везде.

// Готовые ограничения брать проще, чем писать свои: any для чего угодно, comparable для типов, которые можно сравнивать через двойное равно, и потому годящихся в ключи мапы. Именно comparable стоит в сигнатурах обобщённых функций для мап.

тильда в ограничении

~T пропускает сам T и вдобавок любые типы, определённые на его основе

comparable

встроенное ограничение: типы, которые можно сравнивать и класть в ключи мапы

Дженерик или интерфейс

Вопрос решается одним различием. Интерфейс говорит про поведение: мне всё равно, какой тип, лишь бы у него был метод Read. Дженерик говорит про сам тип: мне важно, что вход и выход - один и тот же тип, каким бы он ни был.

Отсюда практика. Нужны разные реализации одного поведения - интерфейс: хранилище, транспорт, кодировщик. Нужна одна и та же логика для разных типов данных с сохранением типизации - дженерик: контейнеры, срезы, кеши, функции вроде Map и Filter.

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

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

Как отвечать: «Зачем дженерики, если есть интерфейсы и any?»

Они решают разные задачи. Интерфейс говорит про поведение: мне неважно, какой тип, лишь бы умел Read. Дженерик говорит про сам тип: мне важно, что вход и выход одного типа, а какого именно - неважно. Через any это тоже пишется, но с потерями: типизация исчезает, на выходе нужны утверждения типа, любая ошибка вылезает во время работы, а не при компиляции, и значения уезжают в кучу при укладке в интерфейс. Дженерик всё это сохраняет: функция Sum принимает []T и возвращает T, компилятор выводит тип из аргументов, скобки при вызове писать не нужно. Про ограничения важна тильда: ~float64 пропускает сам float64 и вдобавок типы, определённые на его основе, поэтому обобщённая функция работает с доменными типами вроде Celsius - я это проверял. Из готовых ограничений чаще всего нужны any и comparable, последнее для ключей мапы. И я стараюсь не обобщать заранее: дженерик оправдан, когда уже есть две-три почти одинаковые функции, отличающиеся только типом.

Разница сформулирована одним критерием, названы конкретные потери от any, показана роль тильды с проверенным примером и добавлено правило, когда обобщать не надо.

На чём валят

• −Берут any там, где нужен дженерик, и теряют типизацию вместе с проверками компилятора.
• −Пишут ограничение без тильды, и функция отказывается работать с доменными типами.
• −Обобщают первую же реализацию заранее, на случай будущей второй.
• −Пытаются описать дженериком поведение, для которого достаточно интерфейса.
• −Забывают про comparable и не могут использовать параметр типа как ключ мапы.
• −Указывают тип в квадратных скобках при вызове, хотя компилятор выводит его сам.