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

Existential-протокол с зафиксированным primary associated type скрывает конкретный тип реализации, сохраняя только гарантии протокола и указанного associated type. Generic-параметр сохраняет identity конкретного типа: Swift знает, что все использования этого параметра в рамках вызова относятся к одному и тому же типу.

Поэтому existential удобен для хранения и передачи разнородных реализаций, а generic — для типобезопасных связей между параметрами, возвращаемыми значениями и associated types.

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

Протоколы с associated types нельзя было использовать как полностью определённый тип значения без уточнения скрытых типов. Например, у разных реализаций одного протокола associated type мог быть разным, поэтому компилятор не мог заранее определить результат операции.

Современный Swift разделяет два сценария: any явно обозначает existential-значение, а primary associated types позволяют зафиксировать важный associated type прямо при использовании протокола. Это делает границу между «скрыть конкретный тип» и «сохранить конкретный тип через generic» более явной.

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

Представим протокол хранилища, у которого тип возвращаемого значения является associated type. На границе модуля нужно принимать разные хранилища, но при этом известно, что каждое возвращает Int.

Если выбрать existential, конкретный тип хранилища будет скрыт. Это удобно для полиморфного хранения, но нельзя будет использовать свойства и связи, доступные только конкретному типу. Если выбрать generic, конкретный тип сохранится, однако такой API не предназначен для хранения произвольного набора разных реализаций в одном значении.

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

Primary associated type фиксируется у existential-протокола, но не раскрывает тип, который реализует сам протокол. В результате значение any Storage<Int> гарантирует, что его операция возвращает Int, однако не сообщает, является ли реализацией IntStorage, CachedStorage или другой тип.

Generic-параметр S: Storage представляет один конкретный тип, выбранный для данного вызова. Если дополнительно установить S.Item == Int, компилятор знает не только результат операции, но и сохраняет identity S: два параметра типа S обязаны быть экземплярами одной конкретной реализации.

Минимальный пример:

protocol Storage<Item> {
    associatedtype Item
    func value() -> Item
}

struct IntStorage: Storage {
    func value() -> Int { 42 }
}

func read<S: Storage>(_ storage: S) -> S.Item {
    storage.value()
}

let concrete = IntStorage()
let number: Int = read(concrete)
let erased: any Storage<Int> = IntStorage()
let other: Int = erased.value()

Вызов через erased знает тип результата Int, но не сохраняет имя и дополнительные возможности IntStorage. Generic-функция, напротив, может связывать S с другими параметрами и возвращать S.Item, сохраняя эти зависимости на всём протяжении вызова.

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

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

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

Сервис принимает разные реализации хранилища чисел: сетевую, кэшированную и тестовую. Если сервис должен хранить выбранную реализацию в одном свойстве и заменять её во время работы, подходящим решением будет any Storage<Int>: тип реализации скрыт, а контракт результата сохранён.

Вариант с generic-классом сохраняет конкретный тип и позволяет связывать его с другими параметрами, но один экземпляр такого класса будет работать с одной выбранной реализацией. Это плохо подходит для массива разнородных хранилищ без дополнительного type erasure.

Выбор existential оправдан на динамической границе, где важнее единый контейнер и слабая связанность с реализацией. Внутри алгоритма, которому нужно сопоставлять несколько параметров одного типа реализации или возвращать S.Item, лучше использовать generic-ограничение. Результатом становится чёткое разделение: type erasure на границе, generics в типобезопасном ядре алгоритма.

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

1. Фиксирует ли any Storage<Int> конкретный тип реализации Storage?

Нет. Фиксируется только значение primary associated type — Int. Конкретный тип, например IntStorage, остаётся скрытым, поэтому нельзя обращаться к его уникальным методам или использовать его имя в типовой связи.

2. Может ли generic-функция получить из existential тот же уровень информации, что из обычного generic-аргумента?

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

3. Почему existential не заменяет generic, даже если primary associated type уже зафиксирован?

Фиксация associated type не восстанавливает все сведения о конкретном типе. Generic сохраняет сам параметр S и позволяет выразить отношения вроде «оба аргумента имеют один и тот же тип реализации» или «результат имеет тип, зависящий от S». Existential предоставляет только заранее объявленные гарантии протокола и потому лучше подходит для стирания типа, но хуже — для точных межтиповых зависимостей.