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

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

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

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

Associated types позволяют протоколу описывать связанные типы, не фиксируя их заранее. Это удобно для контейнеров, последовательностей и адаптеров, где конкретный тип элемента зависит от реализации.

Однако одного объявления associated type часто недостаточно. Например, протокол может требовать наличие элемента, но конкретному алгоритму дополнительно понадобиться, чтобы этот элемент поддерживал Equatable. Ограничение в дочернем протоколе позволяет выразить такой более специализированный контракт один раз и переиспользовать его в generic-коде.

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

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

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

Дополнительное ограничение должно быть частью именно того протокола, который семантически обещает сравнимые элементы. Иначе компилятор не позволит безопасно использовать операцию сравнения через ограничение только базовым протоколом.

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

Дочерний протокол наследует требования базового и добавляет ограничение к его associated type:

protocol Storage {
    associatedtype Item
    var item: Item { get }
}

protocol EquatableStorage: Storage where Item: Equatable {}

struct IntStorage: EquatableStorage {
    let item: Int
}

func sameItem<S: EquatableStorage>(_ lhs: S, _ rhs: S) -> Bool {
    lhs.item == rhs.item
}

В EquatableStorage имя Item относится к associated type, унаследованному от Storage. Запись where Item: Equatable означает: любой тип, соответствующий EquatableStorage, должен иметь такой Item, который соответствует Equatable.

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

Ограничение усиливает контракт, но не меняет базовый протокол. Тип, соответствующий только Storage, может использовать любой Item; он не обязан соответствовать EquatableStorage. Кроме того, соответствие Storage не поднимается автоматически до дочернего протокола.

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

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

В библиотеке есть хранилища значений. Большинство операций требуют только чтения item, но модулю синхронизации нужно сравнивать локальное и удалённое значения.

Первый вариант — оставить один Storage и добавить S.Item: Equatable в каждую функцию синхронизации. Плюс такого решения — гибкость; минус — повторение ограничения и риск, что одна из функций будет объявлена слишком широко.

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

Оптимальное решение — сохранить Storage как общий контракт и добавить EquatableStorage как специализированный refinement. Функции чтения принимают Storage, а функции сравнения — EquatableStorage. В результате уровень абстракции точно соответствует требованиям операции, а ограничение сравнимости объявляется в одном месте.

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

Вопрос: Станет ли тип, соответствующий базовому протоколу, автоматически соответствовать дочернему, если его associated type уже удовлетворяет дополнительному ограничению?

Ответ: Нет. Соответствие протоколу — отдельное объявление или результат условного соответствия, проверяемый компилятором. Даже если Item фактически соответствует Equatable, тип, соответствующий Storage, не начинает автоматически соответствовать EquatableStorage. Это позволяет не смешивать публичные контракты и не менять поведение существующих обобщённых API.
Вопрос: Можно ли в дочернем протоколе ослабить ограничение associated type, унаследованное от базового протокола?

Ответ: Нет. Дочерний протокол сохраняет все требования базового и может только добавить более строгие условия. Если базовый протокол требует, чтобы associated type соответствовал некоторому протоколу или совпадал с конкретным типом, дочерний не может разрешить более широкий набор типов. Иначе соответствие дочернему протоколу перестало бы гарантировать требования базового.
Вопрос: Когда лучше ограничивать associated type в дочернем протоколе, а когда — непосредственно в generic-функции?

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