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

Если метод объявлен только в расширении протокола, через existential-значение вызывается реализация из расширения. Одноимённый метод конкретного типа не переопределяет её для такого вызова, потому что этот метод не входит в таблицу witness’ов протокола.

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

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

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

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

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

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

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

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

Метод, объявленный требованием протокола, получает запись в таблице соответствия протоколу. Когда значение используется как any P, Swift обращается к этой таблице и выбирает реализацию, предоставленную конкретным типом.

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

protocol Renderable { }

extension Renderable {
    func render() -> String { "default" }
}

struct Screen: Renderable {
    func render() -> String { "screen" }
}

let value: any Renderable = Screen()
print(value.render())       // default
print(Screen().render())    // screen

В первом вызове статический тип value — any Renderable, поэтому выбирается метод расширения. Во втором вызове статический тип известен как Screen, и вызывается метод самого типа.

Чтобы поведение выбиралось через соответствие протоколу, метод нужно объявить в теле протокола, а реализацию оставить в extension. Тогда собственная реализация Screen будет использоваться и через existential-значение.

Такое правило относится именно к выбору реализации. Сам метод из extension может быть доступен через existential, если его ограничения совместимы с этим existential. Наличие associatedtype, Self-ограничений или дополнительных where-условий может отдельно ограничить возможность вызова.

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

В библиотеке есть протокол форматирования документов. Разработчик добавил format() только в extension, чтобы предоставить стандартный текст, а конкретные документы объявили собственные версии метода. Внутри приложения документы иногда передаются как [any Document].

Рассматривались два варианта:

оставить format() только в extension — проще для минимального протокола, но вызовы через existential будут использовать общий формат;
объявить format() требованием протокола и дать default implementation в extension — интерфейс становится немного шире, зато сохраняется полиморфное поведение.

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

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

Вопрос: Достаточно ли добавить одноимённый метод в тип, чтобы он стал реализацией метода из extension?

Ответ: Нет. Если метод не объявлен требованием протокола, он не участвует в механизме соответствия. Совпадение имени и сигнатуры само по себе не превращает его в witness протокола.
Вопрос: Что изменится, если метод изначально объявлен требованием протокола, а default implementation находится в extension?

Ответ: В этом случае extension предоставляет реализацию требования. Если соответствующий тип не объявил собственную реализацию до фиксации соответствия, используется default implementation. Если тип объявил собственную реализацию, она становится witness и вызывается через existential.
Вопрос: Почему добавление нового требования в уже используемый протокол может изменить поведение типов?

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