Ответ.

История вопроса

В Rust модификаторы видимости (pub, pub(crate), pub(super)) появились как механизм для инкапсуляции и четкого контроля доступа к данным и функциям, чего в C не хватало. Идея — ограничить область видимости элементов модуля и дать пользователям библиотеки только то, что действительно нужно.

Проблема

Ключевая сложность — что даже если сама структура объявлена публичной (pub), ее поля по умолчанию остаются приватными. Также часто возникает вопрос: как грамотно организовать доступ к вложенным структурам и модулям, не нарушая инкапсуляцию и не делая API «дырявым» или, наоборот, слишком закрытым.

Решение

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

Пример кода:

mod outer {
    pub struct Exposed {
        pub field: i32,
        hidden: bool,
    }
}

// Использование поля "field" доступно,
// hidden — нет.
let e = outer::Exposed { field: 42, hidden: true };
println!("{}", e.field);
// e.hidden // ошибка компиляции

Ключевые особенности:

• Все поля структуры приватны по умолчанию, даже если сама структура публична.
• Доступ к полям нужно явно разрешать через pub или pub(...).
• pub(crate) и pub(super) дают более точный контроль над уровнем доступа к внутренностям модулей.

Вопросы с подвохом.

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

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

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

Нет, в Rust нет классического наследования как в OOP-языках. Доступ к приватным полям контролируется модулем и существенно ограничен.

Что произойдет, если создать структуру с публичными полями, но объявить модуль приватным?

Структура и ее поля не будут видны вне родительского модуля — модификаторы не выходят за пределы области видимости родительского модуля.

Типовые ошибки и анти-паттерны

• Оставлять структуру публичной, но без публичных полей/методов — бесполезная абстракция.
• Давать избыточный pub, раскрывая внутренности API и усложняя поддержку.
• Ошибочно считать, что pub автоматически делает доступными и поля.

Пример из жизни

** Негативный кейс

Пользователь объявил структуру pub, но все поля остались приватными. В результате внешний код не может её корректно использовать, ни создать экземпляр, ни получить значения.

Плюсы:

• Непреднамеренное ограничение области видимости защищает внутренние данные

Минусы:

• Невозможно использовать структуру вне модуля, даже если это было задумано

** Позитивный кейс

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

Плюсы:

• Гарантия инкапсуляции и стабильности интерфейса

Минусы:

• Требует большего объема шаблонного кода (геттеры/сеттеры)