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

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

Если вычисление аргумента вызывает панику, последующие аргументы не вычисляются, и тело вызываемой функции не запускается.

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

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

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

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

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

Главный риск — скрытая зависимость от порядка внутри одной длинной строки. Хотя Go задаёт этот порядок для аргументов, такой код часто сложнее проверять и сопровождать.

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

Рассмотрим минимальный пример:

package main

import "fmt"

func mark(name string) int {
    fmt.Println(name)
    return 0
}

func use(a, b int) {}

func main() {
    use(mark("первый"), mark("второй"))
}

Сначала будет вычислен mark("первый"), затем mark("второй"), после чего начнётся выполнение use. Выводом будут строки первый, затем второй.

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

Компилятор может оптимизировать программу, но не имеет права изменить наблюдаемое поведение. Если побочных эффектов нет, внутренняя оптимизация может быть незаметна; если они есть, их результат должен соответствовать правилам языка.

Практически лучше не помещать важную последовательность изменений состояния в аргументы одного вызова. Явные промежуточные присваивания делают зависимость от порядка очевидной, хотя для самих аргументов вызова правило слева направо является гарантией Go.

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

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

Вариант оставить единый вызов формально корректен: Go вычислит левый аргумент раньше правого. Плюс — меньше строк; минус — побочный эффект скрыт внутри списка аргументов.

Вариант разделить вычисления на отдельные инструкции немного увеличивает объём кода, зато явно показывает последовательность и упрощает отладку. Был выбран второй вариант: порядок стал очевидным, а изменение обработчика перестало зависеть от неявного эффекта внутри вызова.

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

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

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

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

Нет. Порядок вычисления аргументов и порядок выдачи элементов map — разные правила. Даже если выражение внутри аргумента получает данные из map, порядок обхода map не становится определённым. Если нужен стабильный порядок, ключи следует отдельно собрать, отсортировать и затем обработать.

Может ли компилятор поменять местами аргументы без побочных эффектов?

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