Практическая ситуация: тип имеет метод, возвращающий int. Почему он удовлетворяет параметризованному интерфейсу с результатом int, но не тому же интерфейсу с результатом any?
После подстановки аргумента типа параметризованный интерфейс превращается в обычный интерфейс с конкретными сигнатурами методов. int и any в результате метода не являются взаимозаменяемыми, поэтому тип с методом Get() int реализует Source[int], но не Source[any].
Параметризованные интерфейсы появились как часть обобщений в Go и позволяют описывать типобезопасные контракты, зависящие от типа данных. Это уменьшает потребность в использовании any, приведениях типов и дублировании похожих интерфейсов.
Изначальная практическая проблема — выразить связь между входным или хранимым типом и сигнатурой методов без потери статической проверки. При этом Go сохраняет строгое правило совместимости методов: автоматически подставляемые преобразования, включая преобразование значения в any, не учитываются при проверке реализации интерфейса.
Пусть есть обобщённый интерфейс источника данных. Если разработчик считает, что источник с методом Get() int подходит для интерфейса с методом Get() any, программа не скомпилируется.
Ошибка особенно вероятна при проектировании универсальных API: int действительно можно присвоить переменной типа any, но это правило присваивания не меняет тип метода. Неверное предположение приводит к ошибке на границе API, а не к преобразованию результата во время вызова.
Для каждого набора аргументов типа Go рассматривает отдельную инстанциацию интерфейса. Source[int] требует метод Get() int, а Source[any] — метод Get() any.
Сигнатуры методов должны совпадать точно. Совместимость результата по принципу «int можно положить в any» здесь не применяется: Go не поддерживает ковариантность возвращаемых типов при реализации интерфейсов.
Вызов через Source[int] статически знает, что результат имеет тип int. Если нужен интерфейс Source[any], тип должен явно предоставить метод Get() any; отдельная обёртка может вызвать Get() int и упаковать результат в any.
Преимущество строгого правила — предсказуемость и отсутствие скрытых преобразований. Недостаток — иногда требуется адаптер между близкими контрактами, даже если значения одного типа можно присвоить другому.
В библиотеке есть типизированное хранилище, которое должно использоваться как источник идентификаторов. Реализация возвращает int, а общий слой ошибочно ожидает Source[any].
Первый вариант — ослабить интерфейс до Get() any. Это делает API универсальнее, но лишает вызывающий код статической информации о типе и переносит проверки на места использования.
Второй вариант — изменить реализацию так, чтобы она возвращала any. Это устраняет ошибку совместимости, но ухудшает типобезопасность исходного API и может потребовать приведения типа у каждого потребителя.
Предпочтительный вариант — сохранить Source[int] для типизированного слоя, а при необходимости добавить небольшой адаптер Source[any]. Так контракт остаётся точным, а преобразование явно локализуется в одном месте.
Source[int] тем же интерфейсом, что и Source[any]?Нет. Это разные инстанциации параметризованного интерфейса с разными требованиями к методам. Совпадение исходного шаблона Source[T] не означает совпадения конкретных интерфейсных типов после подстановки аргументов.
int переменной типа any при проверке реализации?Нет. Такое присваивание допустимо для значения, но реализация интерфейса проверяется по сигнатуре метода целиком. Метод Get() int не совпадает с Get() any; Go не вставляет преобразование результата между методом и интерфейсным контрактом.
Get?Нет. В Go нельзя объявить два метода с одинаковым именем только из-за разных возвращаемых типов. Для обоих контрактов понадобится другой метод, обёртка или изменение дизайна интерфейсов; перегрузка методов в Go отсутствует.