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

Нет. Реализация требования протокола должна быть доступна не менее широко, чем соответствие и само требование; private или fileprivate-член не может служить witness для более доступного требования. Иначе код, имеющий право использовать соответствие, не смог бы вызвать требуемый член.

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

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

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

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

Рассмотрим внутренний протокол с требованием метода. Если тип объявит соответствующий метод как private, сам тип может вызывать его внутри ограниченной области, но любой код, которому доступен протокол, не сможет гарантированно обратиться к witness.

Похожая проблема возникает у публичного типа, соответствующего публичному протоколу: реализация требования должна быть public. Объявление соответствия в extension не снижает необходимую видимость его witness-методов.

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

При проверке соответствия Swift сопоставляет каждое требование протокола с конкретным членом типа. Такой член называется witness. Компилятор проверяет не только сигнатуру, но и то, что клиент, видящий соответствие, сможет обратиться к этому witness.

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

Например:

protocol Storable {
    func store()
}

struct Cache: Storable {
    private func store() { }
}

Такое соответствие некорректно: Cache заявляет соответствие Storable, но требуемый метод недоступен на уровне, необходимом для использования этого соответствия. Исправление — повысить видимость store до уровня, требуемого протоколом и соответствием, либо не объявлять это соответствие за пределами закрытой реализации.

Default implementation из extension протокола также подчиняется правилам доступа. Если witness не реализован самим типом, тип может использовать доступную реализацию по умолчанию, но она не должна делать публичное соответствие фактически недоступным.

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

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

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

Вариант с private-методом не подходит: публичное соответствие требует доступного witness, иначе клиентский код не сможет использовать объект как значение протокола. Вариант с публичным методом корректен технически, но может раскрыть лишний API.

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

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

1. Достаточно ли сделать сам тип public, чтобы его приватный метод удовлетворил публичному протоколу?

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

2. Меняется ли правило, если соответствие объявлено в extension?

Нет. Extension может организовать код и добавить соответствие, но не меняет требования к доступности witness-реализаций. Компилятор проверяет соответствие так, будто его объявили в основном теле типа.

3. Можно ли скрыть реализацию за default implementation протокола?

Можно, если сама default implementation доступна на уровне соответствия. Но скрытая реализация типа не должна быть единственным witness для требования, если её уровень доступа ниже уровня, на котором клиенты видят протокол и соответствие.