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

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

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

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

Неявная реализация интерфейсов позволяет объявлять контракт отдельно от типов, которые его реализуют. Код, принимающий интерфейс, не обязан зависеть от конкретной структуры или пакета, а типу не требуется явно регистрировать реализуемые интерфейсы.

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

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

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

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

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

У типа T метод с получателем T входит в набор методов T. У типа *T набор методов шире: он включает методы с получателем T и методы с получателем *T.

Минимальный пример:

package main

import "fmt"

type Saver interface { Save() }
type Document struct{}
func (Document) Save() {}
type SecureDocument struct{}
func (*SecureDocument) Save() {}

func main() {
    var a Saver = Document{}
    var b Saver = &SecureDocument{}
    fmt.Println(a, b)
}

Document{} можно присвоить Saver, потому что его набор методов содержит Save. Значение SecureDocument{} нельзя присвоить Saver: Save есть только у *SecureDocument; указатель &SecureDocument{} интерфейс реализует.

Важно различать две операции. Для адресуемой переменной компилятор может неявно использовать её адрес при обычном вызове метода, например value.Save(). Но при преобразовании значения в интерфейс проверяется набор методов его статического типа, и неявное взятие адреса не добавляет методы указателя.

Выбор получателя — это не только вопрос компиляции. Получатель-значение обычно означает работу с копией, тогда как получатель-указатель позволяет менять исходное состояние и избегает копирования крупных структур. Компромисс указателя — необходимость учитывать nil-указатели и более узкий набор типов, которые могут напрямую удовлетворить интерфейсу.

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

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

Библиотека принимает интерфейс Encoder, а конкретный ReportEncoder хранит изменяемое состояние: например, счётчик обработанных записей. После добавления метода с получателем-указателем пользователи, передававшие ReportEncoder по значению, получают ошибку компиляции.

Возможны варианты:

сделать метод получателем-значением — вызовы по значению станут совместимее, но состояние будет изменяться в копии или структура будет копироваться;
оставить указательный получатель и требовать передачу указателя — сохраняется единое состояние и исключается лишнее копирование, но меняется способ использования API;
добавить адаптер, реализующий интерфейс через значение — повышается совместимость, но появляется дополнительный тип и риск неочевидной семантики копирования.

Рациональный выбор — оставить указательный получатель, если состояние кодировщика должно быть общим между вызовами, и явно принимать или документировать передачу указателя. В результате интерфейс отражает реальную семантику объекта, а ошибка обнаруживается компилятором до запуска программы.

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

Может ли тип T удовлетворять интерфейсу, если все недостающие методы объявлены только у *T?

Нет. Для соответствия интерфейсу проверяется набор методов именно проверяемого типа. T не получает методы с получателем *T, поэтому интерфейс может реализовать *T, но не T.

Обратная ситуация возможна: если метод объявлен у T, его имеют и T, и *T. Поэтому указатель обычно удовлетворяет как интерфейсам, требующим только методов значения, так и интерфейсам, включающим эти методы вместе с собственными методами указателя.

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

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

Следовательно, успешный вызов value.Method() не доказывает, что value можно передать в интерфейс, где требуется этот метод. Для интерфейса нужно явно передать указатель либо изменить набор методов типа.

Как встраивание типов влияет на набор методов и соответствие интерфейсу?

Методы встроенного поля могут быть продвинуты во внешний тип, но результат зависит от того, встроено значение или указатель и какой тип проверяется — T или *T. Поэтому при анализе соответствия нужно учитывать не только методы, объявленные непосредственно во внешнем типе, но и правила продвижения методов.

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