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

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

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

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

При этом соответствие протоколу — не просто набор методов, найденных во время вызова. Swift должен заранее определить реализацию каждого требования, чтобы использовать её через generic-код и таблицу соответствия протоколу.

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

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

Такое решение некорректно: для части специализаций типа метод отсутствует. Если Swift допустил бы безусловное соответствие, generic-код смог бы вызвать требование у типа, для которого реальной реализации нет.

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

При проверке соответствия Swift ищет witness — конкретный член, который реализует каждое требование протокола. Этот witness должен быть доступен во всех случаях, покрываемых объявлением соответствия.

Ограничение extension конкретного типа не становится автоматически частью ограничения соответствия. Поэтому безусловное соответствие требует безусловно доступной реализации:

protocol Usable {
    func use()
}

struct Box<T> { }

extension Box: Usable { }

extension Box where T: Equatable {
    func use() { }
}

Такой код не соответствует требованиям: Box<Int> имеет use, но Box<SomeNonEquatableType> — нет. Ограничение T: Equatable действует только на доступность члена, а не расширяет область безусловного соответствия.

Корректный вариант — связать условие с самим соответствием:

protocol Usable {
    func use()
}

struct Box<T> { }

extension Box: Usable where T: Equatable {
    func use() { }
}

Теперь Box<T> считается Usable только при доказанном соответствии T: Equatable. Generic-код может принять такой тип с ограничением Box<T>: Usable, а Swift гарантирует наличие witness именно в допустимых специализациях.

Альтернативный вариант — сделать протокол или его требование пригодным для всех T, например перенести условную логику внутрь безусловной реализации. Это увеличивает область применимости, но иногда приводит к лишним проверкам, менее точной модели возможностей и менее выразительным ограничениям API.

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

Пусть библиотека предоставляет Cache<Value>, а сериализация значения возможна только для типов, соответствующих Codable. Есть два варианта.

Безусловное соответствие протоколу сериализации потребовало бы реализации для любого Value. Можно добавить универсальную реализацию с ошибкой во время выполнения, но это ухудшает типобезопасность: ошибка обнаруживается поздно, а сам тип выглядит пригодным для сериализации.

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

Предпочтительно объявить условное соответствие Cache<Value> протоколу сериализации при Value: Codable. Тогда компилятор запрещает использовать сериализацию для неподходящих значений, а реализация требования остаётся статически проверяемой. Результат — отсутствие лишних runtime-проверок и более точный контракт библиотеки.

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

Достаточно ли добавить ограничение только к методу extension?

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

Сам по себе — нет. Ограниченный extension протокола добавляет доступный при условии член, но это не делает соответствие типа протоколу условным. Кроме того, вызов такого члена через generic-параметр возможен только там, где компилятор доказал соответствующее ограничение.
Что произойдёт, если тип уже имеет безусловное соответствие, а затем появится более специализированная реализация?

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