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

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

Такой метод не является динамическим требованием протокола, если он не объявлен внутри самого протокола. Это ключевое отличие от dispatch через таблицу соответствия протоколу.

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

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

Цена этой выразительности — необходимость различать статическое разрешение членов и динамический dispatch требований протокола. Иначе один и тот же вызов мог бы иметь разные результаты в зависимости от способа передачи значения.

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

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

Это ожидание опасно: generic-контекст или existential может не содержать достаточного статического доказательства ограничения. В результате вызов через конкретный тип, generic-параметр и any-значение способен выбрать разные реализации.

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

Если метод объявлен только в extension протокола, он не входит в требования протокола. Компилятор разрешает такой вызов статически: анализирует видимый статический тип, доступные extensions и ограничения, доказанные в текущем контексте.

Если один extension не ограничен, а другой применим только к Self, соответствующему дополнительному протоколу, для конкретного типа может быть выбрана специализированная версия. Но через any P скрытый конкретный тип не используется для такого статического выбора: интерфейс existential гарантирует только требования P и необусловленные члены, доступные для этого типа.

Чтобы поведение зависело от динамического соответствия, метод следует объявить требованием исходного протокола. Тогда конкретный тип предоставляет witness для этого требования, а вызов через generic-параметр или existential может использовать протокольный dispatch.

protocol Renderable {
    func render() -> String
}

extension Renderable {
    func render() -> String { "обычный" }
}

struct Card: Renderable {
    func render() -> String { "карточка" }
}

let value: any Renderable = Card()
print(value.render()) // карточка

Здесь render объявлен в протоколе, поэтому реализация Card заменяет default implementation и сохраняется при обращении через existential. Если бы render существовал только в extension, он не был бы протокольным требованием, и собственный одноимённый метод типа не гарантировал бы динамическую замену.

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

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

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

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

Вариант с проверкой типа во время выполнения сохраняет исходный протокол, но добавляет ручной downcast, усложняет код и переносит ошибку выбора на runtime. Предпочтительное решение — объявить необходимое полиморфное действие требованием протокола, а базовую реализацию оставить default implementation.

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

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

Достаточно ли фактического типа для выбора ограниченного метода?

Нет. Для статического разрешения важен тип выражения и ограничения текущего контекста. Если значение объявлено как any P, компилятор не может произвольно использовать свойства скрытого конкретного типа для выбора члена из extension P where ....

Становится ли метод из extension требованием протокола автоматически?

Нет. Только объявления внутри тела протокола формируют его требования и участвуют в witness table. Метод, добавленный исключительно extension, остаётся дополнительным статически разрешаемым членом, даже если его имя совпадает с методом конкретного типа.

Как сделать специализированное поведение полиморфным?

Нужно объявить операцию требованием протокола и предоставить реализацию в конкретном типе либо default implementation в extension. Если поведение действительно зависит от дополнительного протокола, это условие должно быть частью дизайна основного протокола, отдельного протокола или явно проверяться в generic-коде; одно ограниченное extension само по себе не меняет динамический контракт.