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

Swift не поддерживает generic-параметры у протоколов. Вместо этого протокол может объявить associated type — связанный тип, который каждая конкретная реализация выбирает один раз в рамках своей конформности.

Generic-параметр создаёт разные специализации одного типа, тогда как associated type задаёт внутренний типовой элемент конкретного соответствия протоколу. Поэтому один тип не может иметь несколько соответствий одному и тому же протоколу только с разными значениями associated type.

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

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

В Swift связь между реализацией и зависимым типом выражается через associated type. Это позволяет описать, например, что контейнер имеет некоторый тип элемента, не превращая сам протокол в параметризованный шаблон.

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

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

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

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

Associated type объявляется внутри протокола и становится конкретным типом в каждой реализации. Например, один тип может выбрать User, другой — Order; при этом оба соответствуют одному протоколу, но имеют разные значения Entity.

protocol Repository {
    associatedtype Entity
    func load() -> Entity
}

struct UserRepository: Repository {
    func load() -> User { User() }
}

struct User {}

func read<R: Repository>(_ repository: R) -> R.Entity {
    repository.load()
}

В generic-функции R.Entity — это зависимый тип, связанный именно с конкретным параметром R. Компилятор сохраняет эту связь и знает, что результат read имеет тип сущности данного репозитория.

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

Это даёт статическую типобезопасность, но ограничивает смешивание значений. Массив нескольких разных репозиториев нельзя автоматически трактовать как коллекцию с одним известным Entity; для такой задачи применяют type erasure, общий негeneric-протокол или переносят обобщение на владеющий код.

Generic-метод, напротив, может получать новый тип при каждом вызове. Associated type обычно выражает постоянную связь реализации с типом, а не независимый выбор типа для каждого вызова.

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

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

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

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

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

Можно ли передать any Repository в generic-функцию, ожидающую R: Repository?

Не во всех случаях. any Repository — это existential-контейнер, скрывающий конкретный тип соответствующего значения. Generic-функции обычно требуется сохранить конкретный тип R и его связь с R.Entity, тогда как existential скрывает эту связь.

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

Может ли один тип соответствовать одному протоколу с двумя разными associated type?

Нет. У типа существует одно соответствие конкретному протоколу, поэтому associated type получает одно значение в рамках этого соответствия. Две условные конформности к одному протоколу с разными значениями также не создают перегруженные соответствия и приводят к конфликту.

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

Почему associated type нельзя заменить generic-параметром метода во всех случаях?

Generic-параметр метода выбирается отдельно при каждом вызове и не обязан быть единственным типом, связанным с реализацией. Associated type, напротив, является частью контракта конкретного соответствия: все требования протокола используют одну и ту же связанную типовую сущность.

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