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

Метод из ограниченного расширения протокола доступен только тогда, когда статический тип в месте вызова подтверждает все ограничения расширения. Одного ограничения на соответствие базовому протоколу недостаточно: generic-контекст должен отдельно доказывать, что его associated type удовлетворяет нужному ограничению.

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

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

Такой подход разделяет базовый контракт и опциональные возможности. Типу не приходится поддерживать операции, требующие свойств его associated type, если эти свойства ему не гарантированы.

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

Пусть протокол описывает хранилище произвольных элементов. Операция поиска элемента через == возможна только для элементов, соответствующих Equatable.

Если generic-функция знает лишь о соответствии аргумента базовому протоколу, компилятор не может предположить, что его associated type поддерживает сравнение. Попытка вызвать такой метод завершится ошибкой компиляции, даже если фактический тип во время выполнения действительно подходит.

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

Swift проверяет доступность метода по статической информации в текущем контексте. Ограничение расширения where Item: Equatable становится применимым, только если компилятор может вывести это условие из конкретного типа или из ограничений generic-параметра.

protocol Store {
    associatedtype Item
    var items: [Item] { get }
}

extension Store where Item: Equatable {
    func contains(_ item: Item) -> Bool {
        items.contains(item)
    }
}

struct Box<T>: Store {
    let items: [T]
}

func has<T: Store>(_ store: T, item: T.Item) -> Bool where T.Item: Equatable {
    store.contains(item)
}

let result = has(Box(items: [1, 2]), item: 2)

В has второе ограничение явно сообщает, что T.Item соответствует Equatable. Поэтому метод contains из ограниченного расширения доступен. Если оставить только T: Store, вызов не скомпилируется: соответствие конкретного типа Item протоколу Equatable не следует из соответствия T протоколу Store.

Ограничения проверяются во время компиляции, а не по фактическому типу объекта во время выполнения. Поэтому переменная, статически типизированная только как any Store, обычно не позволяет вызвать такую специализированную возможность: конкретный тип Item и его соответствие Equatable скрыты.

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

Есть два основных варианта проектирования:

Ограничить associatedtype прямо в протоколе. Тогда каждый тип, соответствующий протоколу, обязан предоставлять Equatable-элемент, а метод доступен во всех контекстах. Цена — более узкий и менее переиспользуемый протокол.
Оставить протокол общим и ограничить только расширение. Тогда базовый контракт поддерживает больше типов, но вызывающий код обязан явно доказать нужное ограничение.

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

В библиотеке есть общее хранилище Store, используемое для моделей, которые могут быть как сравнимыми, так и несравнимыми. Команда сначала добавила contains в основной протокол и потребовала Item: Equatable.

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

Выбранное решение — оставить базовый протокол без ограничения и поместить contains в расширение с условием Item: Equatable. В результате протокол сохранил широкую область применения, а generic-функции, использующие поиск, явно зафиксировали необходимое ограничение. Ошибка при его отсутствии обнаруживается компилятором непосредственно в месте проектирования API.

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

1. Достаточно ли знать, что конкретный тип соответствует протоколу, чтобы вызвать метод ограниченного расширения?

Нет. Нужно знать также ограничения, указанные в расширении. Соответствие T: Store гарантирует наличие T.Item, но ничего не говорит о том, соответствует ли T.Item протоколу Equatable. Поэтому generic-функции должны объявлять это условие явно.

2. Будет ли метод из ограниченного расширения доступен через any Store, если фактический тип элемента соответствует Equatable?

Не обязательно, и в общем случае нет. При использовании any Store конкретный associated type скрыт за existential-типом, поэтому компилятор не может доказать условие Item: Equatable в точке вызова. Фактического соответствия во время выполнения недостаточно для статической проверки такого метода.

3. Чем отличается ограничение associated type в самом протоколе от ограничения в его расширении?

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