Краткий ответ

Динамическим типом становится фактический тип значения, а не интерфейсное ограничение параметра типа. Ограничение используется компилятором при проверке обобщённого кода и не записывается в интерфейсное значение как runtime-метаданные.

Если параметр типа сам был инстанцирован интерфейсным типом, при упаковке обычно сохраняется динамический тип, уже содержащийся в этом интерфейсном значении.

Исторический контекст

Классические интерфейсы Go обеспечивают динамическую диспетчеризацию: интерфейсное значение хранит динамический тип и соответствующее значение. С появлением generics ограничения стали описывать допустимые типы на этапе компиляции, не превращаясь при этом в отдельный runtime-тип.

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

Постановка проблемы

Ограничение может разрешать несколько конкретных типов или целое множество типов через элементы типа. Ошибочно считать, что после присваивания значения параметра типа интерфейсу внутри окажется само ограничение: это привело бы к неверным type assertions и неправильному выбору ветки type switch.

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

Подробное решение

При присваивании значения параметра типа переменной типа any происходит обычное помещение значения в интерфейс. Если T конкретизирован типом UserID, динамический тип интерфейса будет UserID; если T конкретизирован типом int, динамический тип будет int.

Ограничение, например any, comparable или пользовательский интерфейс, только разрешает или запрещает конкретные инстанцирования и операции над T. Оно не определяет результат %T, type assertion или type switch во время выполнения.

package main

import "fmt"

type UserID int

func inspect[T any](v T) {
	var x any = v
	fmt.Printf("%T
", x)
}

func main() {
	inspect(UserID(7))
	inspect(7)
}

Выводом будут main.UserID и int. Несмотря на одинаковую базовую структуру, это разные динамические типы, поэтому assertion к int для значения UserID не заменяет преобразование типов.

Если T имеет интерфейсный тип, значение уже может содержать собственный динамический тип. Передача такого значения в any не заменяет его ограничением и обычно сохраняет фактический динамический тип. Для nil-интерфейса динамического типа нет, поэтому результатом упаковки будет nil-интерфейс.

Когда алгоритму нужно поведение, общее для всех допустимых типов, предпочтительнее выразить его методами ограничения. Если же нужно специально обработать конкретные runtime-типы, значение можно упаковать в any и проверить через безопасный type switch, понимая, что это связывает код с конкретными типами.

Ситуация из практики

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

Можно использовать отражение: оно позволяет получить тип во время выполнения, но добавляет косвенность и усложняет поддержку. Можно применить type switch по известным типам: это быстрее читается, однако список веток придётся обновлять при добавлении новых типов.

В данном случае разумнее передавать в аудит заранее сформированное описание или интерфейс с методом идентификации. Это устраняет зависимость от внутренних конкретных типов; type switch следует оставлять только для действительно типоспецифичной обработки. В результате ограничение продолжает выполнять свою compile-time роль, а runtime-логика явно работает с фактическими типами.

Что кандидаты часто упускают

Изменится ли динамический тип после преобразования именованного типа к его базовому типу?

Да. Явное преобразование UserID к int создаёт значение типа int, поэтому после упаковки в any динамический тип будет int. Само наличие базового типа у именованного типа не меняет его динамический тип автоматически.

Что произойдёт, если параметр типа ограничен интерфейсом с методами?

При упаковке в any динамическим типом всё равно будет конкретный тип значения, реализующий это ограничение. Интерфейсное ограничение не становится динамическим типом, даже если оно определяет доступные внутри generic-функции методы.

Можно ли type assertion проверить принадлежность значения множеству типов из ограничения?

Напрямую проверить такое множество одной assertion нельзя. Type assertion проверяет конкретный тип или обычный интерфейсный тип во время выполнения, тогда как множество типов ограничения является конструкцией компилятора. Для runtime-проверки нужно перечислить конкретные типы, использовать обычный интерфейс с методами или применить отражение с присущими ему компромиссами.