Получатель метода в Go: копия, которой не видно, и «указатель быстрее», которое неверно

Что здесь на самом деле спрашивают

Лестница почти всегда такая:

1. «Чем отличается получатель-значение от получателя-указателя?» — проверяют, скажете ли вы «копия» или ограничитесь словом «мутирует».
2. «Почему мой метод ничего не изменил?» (с кодом) — та самая копия.
3. «Почему тип не реализует интерфейс?» — про наборы методов.
4. «Go сам берёт адрес? Всегда?» — про адресуемость; здесь чаще всего отвечают «всегда», и это неверно.
5. «Что выбрать по умолчанию и почему?» — проверяют, назовёте ли вы однородность набора, а не «указатель, он быстрее».
6. «Насколько быстрее?» — вопрос на честность: без числа обе крайности одинаково плохи.

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

База: один вопрос, с которого начинается выбор

Метод в Go — это функция, привязанная к типу: c.Inc() вызывает Inc «на» значении c. Само это значение называется получателем, и объявляют его слева от имени метода: func (c Counter) Inc().

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

Поэтому выбор получателя решается не размером структуры и не привычкой команды, а одним вопросом про смысл метода:

Метод работает с копией значения — или должен изменить исходное состояние?

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

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

func (c Counter) IncValue()   { c.n++ }
func (c *Counter) IncPointer() { c.n++ }

Это IncValue(c Counter) и IncPointer(c *Counter). Разница ровно та же, что у любых двух функций с такими сигнатурами, — и никакой магии в получателе нет.

Отсюда сразу два вывода:

• Получатель-значение получает копию. Увеличивать поле копии можно, смысла в этом нет: копия умрёт на выходе из метода.
• Получатель-указатель получает адрес. Копируется одно слово, а идёт оно к оригиналу.

Ловушка в том, что вызов выглядит одинаково: и c.IncValue(), и c.IncPointer() пишутся идентично. Разница видна только в объявлении метода, то есть в другом месте файла, а часто и в другом файле.

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

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

Механизм 1: набор методов — это не стилистика

Наборы методов у T и у *T разные, и разницу видно без компилятора — через reflect:

String объявлен с получателем-указателем, и в набор методов значения он не попал. Проверка реализации интерфейса даёт то же самое:

Причина не в синтаксисе, и её стоит уметь назвать: значение в интерфейсе — копия, и адреса у неё нет. Метод с получателем-указателем не смог бы изменить оригинал; тихо менять копию было бы хуже ошибки сборки. Обратное направление разрешено: у указателя адрес есть, разыменовать его для метода-значения можно всегда.

Спецификация формулирует это одним предложением:

Механизм 2: компилятор берёт адрес сам — но не везде

Вот место, где почти все отвечают «Go сам возьмёт адрес», и это верно только наполовину.

Прежде всего стоит сказать, чем это не является. Автоматическое взятие адреса — удобство синтаксиса, а не изменение набора методов. Набор у T остаётся прежним: компилятор просто дописывает & там, где имеет право. Ровно поэтому присваивание значения интерфейсу из предыдущего раздела не спасается тем же механизмом — там переменной, у которой можно взять адрес, уже нет.

Условие названо в спецификации прямым текстом:

Ключевое слово — адресуемо. Что адресуемо, а что нет, стоит держать списком:

У переменной адрес есть, поэтому c.IncPointer() работает. А у элемента карты адреса нет — карта переезжает при росте, — и

m := map[string]Counter{"k": {}}
m["k"].IncPointer()   // не компилируется

не соберётся вовсе: cannot call pointer method on m["k"]. Обходной путь — map[string]*Counter: переезжает указатель, объект стоит на месте.

И это, как ни странно, хорошая новость. Там, где адреса нет, компилятор отказывается собирать — ошибку видно сразу. Опаснее случай, где адрес есть: там компилятор молча берёт адрес копии, и об этом — следующий раздел.

Механизм 3: три места, где копия возникает незаметно

Все три — частые вопросы «найдите ошибку», и ни одно не ловится компилятором. Числа ниже напечатаны прогоном bench/gorecv/internals.go.

Первое — range по срезу значений. Переменная цикла — копия элемента:

for _, v := range items {
    v.Add()        // меняет копию; срез не изменится
}
for i := range items {
    items[i].Add() // меняет элемент
}

Результат прогона: 0 в первом случае, 1 во втором. Это самая частая из трёх, потому что for _, v := range пишут не задумываясь.

Второе — присваивание структуры. cp := src копирует её целиком, и дальше это два независимых объекта: после cp.Add() в прогоне src=5 cp=6.

Третье — хранение значений там, где нужны указатели. map[string]Acc не даст вызвать метод-указатель вовсе; []Acc даст, но через индекс, а не через переменную цикла.

Общее у всех трёх: вызов выглядит одинаково. Компилятор берёт адрес, когда переменная адресуема, и молчит; когда адреса нет — отказывается собирать. Между этими двумя случаями и живёт ошибка.

Механизм 4: дерево решения

Правило выбора не про скорость. Вопросы задаются по порядку, и первый же ответ «да» закрывает выбор:

Три верхних вопроса — про корректность, и только четвёртый про цену. Вот те же вопросы словами:

1. Метод меняет получателя? Тогда указатель — иначе он меняет копию. Это не рекомендация, а единственный работающий вариант.
2. Тип содержит то, что нельзя копировать? sync.Mutex, sync.WaitGroup, strings.Builder — копия такого типа ломается молча, и go vet ловит это отдельной проверкой copylocks.
3. У части методов уже есть получатель-указатель? Тогда и у остальных пусть будет: иначе набор методов зависит от того, что именно присвоено.

И только если ни один из трёх вопросов не решил дело, остаётся размер. Хорошие кандидаты на получатель-значение — маленькие неизменяемые типы: time.Time, свои обёртки над числом или строкой. Там копия — это признак, а не цена.

Глубже: «указатель быстрее» — зависимость от размера, а не правило

Вот числа, ради которых стоит переключить вкладку на картинке выше. Один и тот же метод — прочитать два поля — на структурах разного размера:

Читать эту таблицу надо снизу вверх. Внизу видно то, о чём спрашивают: копия стоит денег, и на килобайте вызов дороже почти вдесятеро. Наверху видно то, о чём забывают: на одном-двух словах разницы нет вовсе — копировать нечего, значение и так живёт в регистрах.

Поэтому ответ «получатель-указатель быстрее» неверен как правило. Но и обратное правило — «берите значение, копия дешёвая» — неверно ровно так же: нижняя строка таблицы его опровергает.

Верно третье, и оно не правило, а зависимость: дорожает копия, и её цена растёт вместе с размером. Тело метода при этом одинаковое — читаются те же два поля. Сами кратности — свойство этого прогона на этой машине: на другой они выйдут другими, а вот направление ряда — то же.

И размер — лишь один из факторов, причём последний по важности. Указатель заставляет значение уходить в кучу чаще (об этом урок про escape-анализ), а значение даёт компилятору больше свободы. Что перевесит в конкретной функции — меряется профилем, а не выводится из таблицы.

Обратите внимание на слово «большой» — в самом FAQ оговорка стоит после правил про изменение и однородность, а не вместо них.

Как отвечать на собеседовании

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

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

На «в чём разница» отвечайте «получатель — это первый аргумент». «Значение копируется, указатель — нет; всё остальное отсюда». Ответ сразу показывает, что вы не заучили два правила, а понимаете одно.

Про «метод ничего не изменил» называйте место, а не правило. «Скорее всего, for _, v := range: переменная цикла — копия, и метод-указатель поменял её». Это распознаётся как опыт мгновенно.

Про интерфейс говорите про адрес. «У копии в интерфейсе нет адреса, поэтому метод с получателем-указателем в набор методов значения не входит». Формулировка «надо передавать указатель» верна, но не объясняет ничего.

Про автоматическое взятие адреса добавьте оговорку. «Берёт, если выражение адресуемо; у элемента карты адреса нет, и там это не компилируется». Половина кандидатов отвечает «всегда».

Про скорость дайте диапазон, а не крайность. «Разница — это цена копии: до восьми слов её нет вовсе, на килобайте выходило вдесятеро». Одно число без второго превращает верный замер в неверное правило.

Про выбор по умолчанию назовите однородность. «Если хоть одному методу нужен указатель — указатель у всех, чтобы набор методов не зависел от того, что присвоено».

Дальше спросят

Частые заблуждения

Практика

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

func (c Counter) IncValue() { c.n++ }

func (c *Counter) IncPointer() { c.n++ }

c := Counter{}
c.IncValue()
c.IncPointer()
fmt.Println(c.n)

cs := []Counter{{}, {}}
for _, v := range cs {
	v.IncPointer()
}
fmt.Println(cs[0].n)

for i := range cs {
	cs[i].IncPointer()
}
fmt.Println(cs[0].n)

p := &Counter{}
p.IncValue()
fmt.Println(p.n)

1
0
1
0

2
1
2
1

1
1
1
1

2
0
1
0

Проверка знаний