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

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

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

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

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

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

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

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

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

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

Swift проверяет условие ограниченного расширения при формировании конкретной специализации. Если параметр типа удовлетворяет ограничению, специализация получает соответствие протоколу и его требования; иначе соответствия нет.

protocol CacheKey {
    associatedtype Key: Hashable
    var key: Key { get }
}

struct Box<Value> {
    let value: Value
}

extension Box: CacheKey where Value: Hashable {
    typealias Key = Value
    var key: Value { value }
}

func store<T: CacheKey>(_ item: T) { }

store(Box(value: 42))

Для Box<Int> условие Value: Hashable выполнено, поэтому вызов store допустим. Для Box с нехешируемым значением соответствия CacheKey нет, и передать такую специализацию в store нельзя.

Связь Key == Value в примере выводится из объявления typealias Key = Value. Ограничение на associatedtype в протоколе гарантирует, что выбранный тип ключа поддерживает Hashable, а ограничение расширения гарантирует, что сама специализация контейнера способна предоставить такой ключ.

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

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

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

В библиотеке есть обобщённый Box<Value>, который используется для хранения объектов в кэше. Ключом кэша можно сделать значение только для типов, поддерживающих Hashable; для остальных значений такая операция некорректна.

Рассматривались два варианта. Первый — добавить хеширование непосредственно в Box, но это неверно моделирует возможности всех специализаций и усложняет тип. Второй — создать отдельный тип вроде HashableBox, что делает модель явной, но приводит к дублированию API и преобразованиям между контейнерами.

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

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

Можно ли использовать условное соответствие, если generic-функция ограничена только самим контейнером?

Нет, если её ограничения не позволяют доказать условие расширения. Например, параметр функции, объявленный лишь как произвольный Box<Value>, не даёт оснований считать Value хешируемым. Нужно добавить ограничение Value: Hashable или принять параметр через протокол, который уже гарантирует нужное соответствие.

Является ли условное соответствие отдельным соответствием для каждой специализации?

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

Что произойдёт, если два ограниченных расширения потенциально предоставляют один и тот же протокол?

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