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

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

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

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

До появления обобщений в Go 1.18 повторяющуюся логику часто реализовывали отдельными функциями для разных типов либо принимали через interface{} и затем выполняли утверждения типа. Первый вариант увеличивал объём кода, второй переносил часть проверок на время выполнения и мог завершиться паникой.

Generics решают задачу повторного использования алгоритмов без отказа от статической проверки типов. Интерфейсные ограничения стали способом описать не только допустимые типы, но и гарантированный набор операций над параметром типа.

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

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

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

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

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

package main

import "fmt"

type Named interface {
	Name() string
}

func PrintName[T Named](v T) string {
	return v.Name()
}

type User struct{ name string }

func (u User) Name() string { return u.name }

func main() { fmt.Println(PrintName(User{"Ada"})) }

Здесь PrintName может вызвать Name, потому что этот метод входит в ограничение Named. Тип User удовлетворяет ограничению благодаря методу с тем же именем, сигнатурой и получателем; при выводе типа параметр T становится User.

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

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

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

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

В библиотеке нужно форматировать разные сущности по их отображаемому имени. Рассматривались три варианта: отдельная функция для каждого типа, interface{} с утверждением типа и обобщённая функция с ограничением Name() string.

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

Выбран третий вариант: ограничение выражает реальное требование алгоритма, а не перечень известных на данный момент типов. В результате новый тип подключается добавлением метода Name, без изменения самой функции; ошибочный тип отклоняется компилятором до запуска программы.

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

Допустим ли вызов метода, которого нет в ограничении, если он есть у фактического типа?

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

Что происходит с методом, если ограничение допускает несколько типов, но метод есть только у одного из них?

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

Можно ли заменить интерфейсное ограничение на interface{} и сохранить ту же статическую безопасность?

Нет. Пустой интерфейс допускает любое значение и не сообщает компилятору, что у него есть нужный метод. Для вызова метода придётся выполнить утверждение типа, использовать type switch или отражение; ошибки переместятся в runtime, а часть гарантий потеряется. Интерфейсное ограничение предпочтительнее, когда алгоритму нужен конкретный контракт, потому что оно одновременно описывает требование и проверяет его при компиляции.