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

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

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

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

Такой синтаксис удобен для локальных структур и небольших типов, однако плохо подходит для публичных API: изменение представления структуры становится изменением контракта для всех пользователей пакета.

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

Предположим, пакет публикует структуру, а другой пакет создаёт её позиционным литералом. Если автор API добавит поле, старый литерал перестанет соответствовать количеству полей. Если поля поменяют местами, код может либо перестать компилироваться из-за типов, либо продолжить работу с другим смыслом значений, если типы совпадают.

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

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

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

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

package api

type Config struct {
    Host string
    Port int
}

package main

import "example/api"

func main() {
    _ = api.Config{Host: "localhost", Port: 8080}
}

Если в Config добавить поле Timeout, именованный литерал продолжит компилироваться, а api.Config{"localhost", 8080} — нет: в нём отсутствует значение для нового поля. При перестановке Host и Port позиционный литерал может получить ошибку типов, а при одинаковых типах полей — сохранить компилируемость, но изменить поведение.

Для публичных структур обычно выбирают именованные литералы либо функцию-конструктор. Именованные литералы проще и позволяют явно увидеть важные поля, но вызывающий код всё равно получает прямой доступ к представлению типа. Конструктор скрывает детали, централизует проверки и позволяет менять внутреннее устройство структуры, но добавляет функцию API и может усложнить создание вариантов значения.

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

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

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

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

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

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

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

Ломает ли добавление поля именованный литерал?

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

Нет, внешний пакет не может корректно задать значение неэкспортируемого поля. Для публичного типа с такими полями следует использовать именованные экспортируемые поля, конструктор или фабричную функцию. Это позволяет владельцу пакета контролировать создание значения и поддерживать инварианты.
Почему одинаковые типы полей делают перестановку особенно опасной?

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