Параметры типов и constraints: множества типов, пределы вывода и GCShape-стенсилинг

Constraints — множества типов, а не иерархии классов

Список параметров типа — func Sum[T Number](xs []T) T — вводит T как плейсхолдер, который должен удовлетворять своему constraint. Constraint — это обычный интерфейс, но в новой роли: вместо того чтобы описывать, что значение умеет делать, он описывает множество типов, которые разрешены. Внутри такого интерфейса можно перечислять типы напрямую, объединять их через | и ставить префикс ~, означающий «любой тип, чей underlying type — вот этот»:

// Constraint — это интерфейс, используемый как множество типов.
type Number interface {
	~int | ~int64 | ~float64 // ~T: любой тип с underlying-типом T
}

func Sum[T Number](xs []T) T {
	var total T
	for _, x := range xs {
		total += x // легально: каждый тип множества поддерживает +
	}
	return total
}

type Celsius float64 // именованный тип, underlying — float64

var _ = Sum([]Celsius{20.5, 21.0}) // компилируется только благодаря ~

Тильда важнее, чем кажется. Код на Go полон именованных типов — type UserID int64, type Port int, — а constraint, записанный как голый int64, допускает только int64, но не UserID. Без тильды ваша «числовая» библиотека отвергает половину доменных типов кодовой базы, причём провал — это ошибка компиляции у вызывающего, далеко от constraint, который её вызвал. Эмпирическое правило: в переиспользуемых constraints всегда пишите ~T, если нет конкретной причины исключить именованные типы. Словарь дополняют ещё две детали: comparable — предобъявленный constraint со смыслом «поддерживает == и !=» (именно он нужен ключам map, и его нельзя выразить объединением — множество бесконечно), а ещё constraints могут содержать методы, и тогда тип должен одновременно входить в множество и иметь эти методы. Чего constraint не может никогда — выступать обычным типом: нельзя объявить var n Number; множества типов существуют только в момент инстанцирования.

Вывод типов: мощный в точке вызова, отсутствующий везде ещё

Прежде чем рассчитывать на вывод типов для чистоты вызовов, стоит знать, где он просто останавливается, — чтобы поймать запах дизайна до того, как о него споткнётся коллега.

Вывод типов — то, что делает дженерики читаемыми: Sum(prices) вместо Sum[Celsius](prices). Компилятор выводит аргументы типов из типов аргументов функции и затем проверяет их по constraints. Но у вывода есть жёсткие края, и senior-ревью означает знать, где они:

func Map[T, U any](xs []T, f func(T) U) []U { /* ... */ }

ys := Map(ids, strconv.Itoa) // T=int, U=string — выведены из аргументов

func Zero[T any]() T { var z T; return z }

v := Zero[int]() // обязательное явное инстанцирование:
                 // T встречается только в результате — выводу не на что смотреть

Параметр типа, который встречается только в позиции результата, вывести нельзя никогда — нет аргумента, несущего информацию. Нетипизированные константы — вторая ловушка: передача 1 в параметр [T Number] выводит int (тип константы по умолчанию), а не int64, и если constraint исключает int, вызов не компилируется, хотя 1 — совершенно валидный int64. Третий предел структурный: вывод работает только в точках вызова. Нет вывода из контекста присваивания, нет частичной специализации, нет перегрузки по constraints. Когда вывод не срабатывает, фикс механический — написать аргумент типа явно, — но API, который регулярно заставляет вызывающих писать F[конкретный](...), — это запах дизайна, лечащийся переносом параметра типа в аргумент.

Инстанцирование: GCShape-стенсилинг, честно

Что происходит, когда вы реально вызываете Sum[Celsius]? C++ бы мономорфизировал: сгенерировал свежий машинный код под каждый аргумент типа — быстрый код, медленная компиляция, толстые бинарники. Java стирает типы: одна копия кода, всё в боксах. Go 1.18 выбрал середину — GCShape-стенсилинг со словарями. Компилятор группирует аргументы типов по GC-шейпу: два типа делят шейп, если для аллокатора и сборщика мусора они выглядят одинаково — тот же размер, та же раскладка указателей. Но главный коллапс вот в чём: все типы-указатели — один шейп. *User, *Order, *bytes.Buffer — одно общее инстанцирование. Чтобы различать их в рантайме, компилятор передаёт скрытый аргумент-словарь с метаданными конкретного типа: его runtime._type, адреса методов, производные типы. Код, вызывающий метод параметра типа, загружает адрес из словаря и вызывает косвенно — а значит, через этот вызов нет инлайнинга.

Честные последствия для производительности: инстанцирования с типами-значениями получают выделенный код, прямые вызовы, полный инлайнинг — реальный выигрыш над версиями с interface{}, которым приходилось боксить и делать assertions. Инстанцирования с указателями получают общий код и косвенные вызовы через словарь — примерно профиль стоимости интерфейсного вызова метода, иногда чуть хуже из-за лишней загрузки словаря. Ровно в этот шов и врезалась команда из Hook: Cache[string, int64] мономорфизировался; Cache[string, *Session] пошёл через словарь. Стенсилинг — деталь реализации, которую спецификация не обещает (стратегия gc остаётся шейповой с 1.18), но проектировать API так, будто дженерики — бесплатная мономорфизация, — верный способ занести бенчмарк-сюрпризы в продакшен-ревью.