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

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

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

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

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

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

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

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

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

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

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

package api

type Config struct {
    Name string
    token string
}

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

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

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

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

Рассматривались два варианта. Открыть поле токена проще, но это разрушает инкапсуляцию; использовать именованный литерал безопаснее, однако он не позволяет задать закрытый токен. Выбран конструктор пакета, который принимает токен, проверяет его и сохраняет во внутреннем поле.

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

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

Можно ли из другого пакета использовать именованный литерал, если у структуры есть закрытые поля?

Да, если задаются только экспортируемые поля. Неуказанные поля получают нулевые значения. Нельзя указывать имя неэкспортируемого поля, потому что оно недоступно за пределами объявившего его пакета.

Почему позиционный литерал запрещён даже при наличии только экспортируемых значений, которые хочет задать клиент?

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

Всегда ли конструктор лучше именованного литерала?

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