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

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

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

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

До появления generics методы в Go имели фиксированные сигнатуры и входили в методный набор типа, что позволяло интерфейсам проверять совместимость по именам и точным сигнатурам методов.

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

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

В примере разработчик ожидает, что Map будет универсальным для любого T. Однако запись Map[T any] пытается добавить параметр типа именно методу, а такой синтаксис в Go запрещён.

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

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

Параметр типа может принадлежать функции:

package main

func Map[T any](v T) T {
	return v
}

type Box[T any] struct{ Value T }

func (b Box[T]) Get() T { return b.Value }

Здесь Map — generic-функция, а Get — обычный метод обобщённого типа Box[T]. Метод использует T, полученный от типа-получателя, но не объявляет новый параметр типа самостоятельно.

Вызов Map(10) выводит T как int, а Box[string] имеет метод Get() string. Для каждого конкретного экземпляра Box[T] метод получает соответствующую конкретную сигнатуру.

Интерфейс может описывать такие конкретные методы, например interface { Get() string }, но не метод вида Map[T any](T) T. Если операции требуется принимать значения разных типов, обычно выбирают generic-функцию; если тип фиксируется на уровне объекта, — обобщённый тип.

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

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

Допустим, библиотека должна преобразовывать значения разных типов. Вариант с методом Map[T] был бы удобен синтаксически, но не компилируется и не может быть описан обычным интерфейсом.

Generic-функция решает задачу напрямую: она допускает отдельный T для каждого вызова и хорошо выводит тип из аргумента. Минус — операцию нельзя выразить как метод конкретного объекта и передать через интерфейсный метод.

Обобщённый тип подходит, если тип данных известен при создании объекта: например, Box[int] или Box[string]. Плюс — методы получают стабильную сигнатуру после специализации; минус — один объект такого типа не становится универсальным контейнером для произвольных T.

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

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

Можно ли объявить generic-метод, если сам receiver — обобщённый тип?

Нет, новый параметр типа у метода всё равно запрещён. Разрешено использовать параметры типа receiver-типа:
```
type Box[T any] struct{ Value T }

func (b Box[T]) Get() T { return b.Value }
```
Здесь T принадлежит Box[T], а не методу Get.
Можно ли заменить запрещённый generic-метод методом с any?

Технически метод Map(any) any допустим, но это уже не эквивалентная замена. Типовая проверка переносится на вызывающий код, а конкретный тип результата теряется и может потребовать type assertion.

Generic-функция Map[T any](T) T сохраняет связь между типом аргумента и результатом, поэтому обычно безопаснее и точнее.
Может ли интерфейс требовать один конкретный экземпляр метода обобщённого типа?

Да. Например, после выбора Box[int] его метод может иметь сигнатуру Get() int, и интерфейс interface { Get() int } будет реализован этим конкретным типом.

Но интерфейс не может потребовать метод, который сам параметризуется для любого T. В Go интерфейс сопоставляет фиксированные сигнатуры методов, а не семейство сигнатур generic-метода.