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

Нет. Реализация метода сама по себе не означает соответствие протоколу: условительное приведение будет успешным только для типа, у которого соответствие протоколу явно объявлено или предоставлено через другое объявление соответствия.

Swift не использует «утиное» типизирование для таких приведений. Наличие методов проверяемой сигнатуры не заменяет сведения о соответствии типа протоколу.

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

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

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

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

Если ошибочно считать совпадение методов соответствием протоколу, можно ожидать успешного приведения значения из Any к протоколу и вызвать протокол-ориентированный код. На практике приведение вернёт nil, потому что проверяется не форма объекта, а зарегистрированное соответствие его динамического типа.

Это особенно важно на границах модулей и при работе с Any: компилятор может разрешить объявить метод с нужной сигнатурой, но это не делает тип участником полиморфизма протокола.

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

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

protocol Describable {
    func describe() -> String
}

extension Describable {
    func describe() -> String { "по умолчанию" }
}

struct Item {
    func describe() -> String { "совпадает по форме" }
}

let value: Any = Item()
print(value as? any Describable == nil) // true

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

Если добавить соответствие, например объявив Item: Describable, приведение станет успешным. При этом конкретный тип Item не исчезает из объекта, но через значение existential-типа any Describable вызывающему коду доступен только интерфейс протокола и разрешённые им операции.

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

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

Команда принимает плагины как Any и хочет находить среди них объекты, реализующие протокол Renderable. Один из типов содержит метод render, скопированный по сигнатуре, но не объявляет Renderable; попытка условительного приведения пропускает этот объект.

Вариант с проверкой наличия метода неприменим: Swift не предоставляет общего безопасного механизма проверки произвольного метода у значения Any, а такой подход также не учитывал бы остальные требования протокола. Принудительное приведение не решает проблему и добавляет риск аварийного завершения.

Правильное решение — явно объявить соответствие типа Renderable и использовать условительное приведение. Это делает контракт видимым для компилятора, позволяет применять default implementation и гарантирует, что в плагин действительно входит полный протокольный контракт.

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

Может ли расширение типа добавить соответствие протоколу, если в нём нет собственных методов протокола?

Да. Если все требования покрываются реализациями по умолчанию, расширение может объявить соответствие без написания новых методов. Сам факт объявления соответствия всё равно обязателен: default implementation удовлетворяет требования, но не регистрирует conformance автоматически.

Что изменится, если метод с такой же сигнатурой добавить после объявления соответствия протоколу?

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

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

Протокол описывает не только имена методов. Он может требовать свойства, ассоциированные типы, другие протоколы и конкретные ограничения на сигнатуры. Поэтому runtime-проверка conformance должна опираться на формально объявленное соответствие, а не на частичное совпадение структуры типа.