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

Унаследованный метод базового класса может стать witness — реализацией требования протокола для наследника. Наличие extension с соответствием не заставляет Swift выбирать default implementation из расширения протокола: при формировании соответствия компилятор учитывает доступные члены самого класса, включая унаследованные.

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

Протоколы Swift отделяют описание требований от конкретных реализаций. Это позволяет классу или структуре получить соответствие в отдельном extension, не меняя основное объявление типа, а default implementation в extension протокола служит запасным вариантом.

Для поддержки полиморфного вызова Swift формирует таблицу соответствия протоколу — набор ссылок на реализации его требований. Выбор witness обычно фиксируется при проверке соответствия, поэтому порядок и место объявления членов могут влиять на результат.

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

Рассмотрим класс с унаследованным методом и протокол с одноимённым требованием. Если разработчик ожидает, что соответствие в extension автоматически выберет default implementation протокола, поведение может оказаться неожиданным: вызов через протокол и generic-код будут использовать унаследованный метод.

Неверный выбор реализации особенно опасен, если базовый класс находится в другом модуле или его поведение неочевидно. Добавление собственного метода в extension после объявления соответствия также не следует рассматривать как надёжный способ заменить уже выбранный witness.

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

При проверке соответствия Child: P Swift ищет реализацию требования среди членов Child, включая унаследованные методы. Если подходящий метод найден, он используется как witness. Default implementation из extension протокола применяется только когда конкретный тип не предоставляет подходящего члена.

Минимальный пример:

protocol Renderable {
    func render() -> String
}

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

class Base {
    func render() -> String { "base" }
}

class Screen: Base, Renderable {}

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

Здесь Screen получает соответствие Renderable, а метод render уже доступен через Base. Поэтому witness указывает на реализацию базового класса, а не на default implementation протокола.

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

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

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

В библиотеке есть базовый класс BaseView с методом render, а команда добавляет протокол Renderable и объявляет соответствие конкретного наследника в extension. Рассматривались два варианта: удалить метод из базового класса и положиться на default implementation протокола либо сохранить метод класса и добавить соответствие.

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

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

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

Может ли default implementation протокола заменить унаследованный метод?

Нет, если унаследованный метод уже подходит под требование. Default implementation — это запасная реализация, а не более приоритетная версия. Она используется, когда тип не предоставляет собственного или унаследованного подходящего witness.

Достаточно ли добавить одноимённый метод в extension наследника после объявления соответствия?

Нет, это не универсальный способ изменить witness. Соответствие проверяется как единая декларация, и выбранная реализация требования фиксируется в его metadata. Кроме того, extension класса не превращает обычный метод в переопределение базового метода без соблюдения правил наследования и диспетчеризации.

Почему наличие метода с такой же сигнатурой особенно важно именно для требований протокола?

Потому что только объявленное требование участвует в таблице соответствия и может вызываться полиморфно через any P или generic-ограничение T: P. Метод, существующий лишь в extension протокола, но не объявленный как требование, не становится динамическим witness для каждого типа автоматически; его выбор определяется статическим типом и правилами разрешения членов.