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

Программа напечатает extension. Метод describe() объявлен только в расширении протокола, поэтому он не является требованием протокола и выбирается статически по типу any Describable; реализация класса не участвует в динамической диспетчеризации.

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

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

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

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

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

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

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

В примере статический тип переменной value — any Describable. Протокол Describable не содержит требования describe(), поэтому вызов разрешается как вызов метода из расширения протокола. Результат — строка extension.

Метод Item.describe() не переопределяет метод расширения. Он лишь создаёт одноимённый метод, доступный при обращении к значению как к Item:

protocol Describable {}

extension Describable {
    func describe() -> String { "extension" }
}

final class Item: Describable {
    func describe() -> String { "class" }
}

let concrete = Item()
let abstracted: any Describable = concrete
print(concrete.describe())   // class
print(abstracted.describe()) // extension

Для динамического выбора реализацию нужно объявить требованием протокола:

protocol Describable {
    func describe() -> String
}

extension Describable {
    func describe() -> String { "default" }
}

final class Item: Describable {
    func describe() -> String { "class" }
}

let value: any Describable = Item()
print(value.describe()) // class

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

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

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

Предположим, есть протокол Loggable с методом форматирования сообщения. Команда добавила format() только в расширение протокола, а один из типов реализовал собственный format(). При обработке массива [any Loggable] ожидалась индивидуальная сериализация каждого объекта, но все элементы использовали реализацию расширения.

Вариант с оставлением метода только в расширении имеет плюс: общий код минимален. Минус — невозможно получить полиморфный вызов через протокольный тип.

Вариант с ручным приведением каждого значения к конкретному типу устраняет проблему лишь частично: он усложняет код, требует перечислять типы и нарушает абстракцию. Выбранное решение — объявить format() требованием Loggable, сохранив реализацию по умолчанию в расширении.

После этого каждый тип может переопределить форматирование, а код, работающий с [any Loggable], получает корректную реализацию через witness-диспетчеризацию. Общая реализация остаётся доступной для типов, которым достаточно поведения по умолчанию.

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

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

Да. При обращении к Item компилятор видит метод Item.describe() напрямую, поэтому Item будет напечатан. Отличие появляется при обращении через any Describable или другой протокольный статический тип.

Достаточно ли добавить одинаковую сигнатуру в протокол позже через расширение?

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

Одинаково ли ведёт себя вызов в обобщённой функции и через any?

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

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