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

Для associated type можно указать составное ограничение: соответствующий тип должен одновременно реализовывать несколько протоколов. В generic-коде это даёт доступ ко всем требованиям этих протоколов, но не связывает associated type с каким-либо конкретным типом.

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

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

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

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

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

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

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

Ограничения можно объединить через составной протокол. Например:

protocol Repository {
    associatedtype Key: Hashable & Comparable
    func load(_ key: Key)
}

func useRepository<R: Repository>(_ repository: R, key: R.Key) {
    let _ = key.hashValue
    let _ = key < key
    repository.load(key)
}

Здесь R.Key обязан соответствовать одновременно Hashable и Comparable. Поэтому тело useRepository может использовать hashValue и оператор сравнения без дополнительных ограничений.

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

Составное ограничение не гарантирует равенство associated type разных реализаций. Если generic-функция работает с двумя параметрами, их связанные типы останутся независимыми, пока явно не задано same-type constraint. Также составное ограничение не добавляет новых требований сверх объединённых протоколов.

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

В библиотеке есть универсальное хранилище ключей. Одни ключи нужно сравнивать для сортировки, другие — использовать в хеш-таблице, поэтому хранилище требует Comparable & Hashable.

Вариант с конкретным типом, например Int, прост, но исключает пользовательские ключи. Вариант с одним Hashable позволяет хранить ключи, но не даёт сортировку. Создание отдельного протокола вроде SortableKey может быть оправдано, если такое сочетание является устойчивой частью предметной модели; для локального generic-ограничения составной протокол короче и не создаёт лишнего публичного API.

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

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

1. Равны ли associated type двух generic-параметров, если оба ограничены одинаковым составным протоколом?

Нет. Общее соответствие Hashable & Comparable ограничивает возможности типов, но не делает их одним и тем же типом. Для равенства требуется отдельное same-type constraint.

2. Можно ли заменить составное ограничение новым протоколом-наследником без изменения смысла?

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

3. Делает ли составное ограничение сам associated type existential-типом?

Нет. В объявлении generic-ограничения оно описывает требования к конкретному подставленному типу. Generic-код сохраняет статическую связь с этим типом, поэтому его операции проверяются и обычно специализируются компилятором; это не то же самое, что хранение значения как existential any нескольких протоколов.