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

Требование, объявленное в протоколе, вызывается через динамическую реализацию конкретного типа. Метод, существующий только в extension протокола, выбирается статически по видимому типу — any Protocol, поэтому одноимённая реализация конкретного типа не переопределяет его для existential-значения.

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

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

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

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

Предположим, несколько типов соответствуют одному протоколу. Один метод объявлен требованием протокола, а другой существует только в его extension. Если затем скрыть конкретный тип за any Protocol, внешне оба метода могут выглядеть одинаково доступными.

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

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

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

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

protocol Describable {
    func describe()
}

extension Describable {
    func describe() { print("по умолчанию") }
    func category() { print("категория по умолчанию") }
}

struct Note: Describable {
    func describe() { print("заметка") }
    func category() { print("категория заметки") }
}

let value: any Describable = Note()
value.describe() // заметка
value.category() // категория по умолчанию

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

Это правило относится к диспетчеризации методов. Оно не означает, что объект копируется или меняет свой динамический тип: existential лишь скрывает конкретный тип за протокольным интерфейсом.

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

В библиотеке есть протокол форматирования документов и расширение с методом formatForLog. Команда добавляет в конкретный тип собственную версию formatForLog и ожидает, что общий логгер начнёт использовать её через значение any Formatter.

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

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

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

Будет ли вызвана реализация конкретного типа, если переменная имеет сам тип структуры, а не any Protocol?

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

Что изменится, если добавить метод из extension в тело протокола?

Он станет требованием протокола. После этого реализация конкретного типа будет зарегистрирована как соответствие требованию и будет вызываться динамически через existential. Реализация по умолчанию из extension сохранится как fallback для типов, которые не предоставили собственную.

Означает ли вызов реализации extension, что приведение к протоколу прошло неуспешно?

Нет. Успешное приведение определяет, можно ли обращаться к значению через протокольный контракт. Выбор реализации метода — отдельный вопрос диспетчеризации. Значение по-прежнему содержит экземпляр исходного конкретного типа, но доступные члены и способ их вызова зависят от статического типа выражения и требований протокола.