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

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

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

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

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

Однако обычный протокол как existential-тип должен скрывать конкретную реализацию. В современных версиях Swift запись any P явно показывает такое стирание типа, тогда как обобщённый параметр сохраняет конкретную связь между значением и его ассоциированным типом.

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

Предположим, существуют две реализации одного протокола: одна содержит Int, другая — String. Их можно поместить в коллекцию типа any P, потому что внешний коду достаточно знать, что оба значения соответствуют протоколу.

Но обращение к P.Item было бы неоднозначным: для одного элемента это Int, для другого — String. Если использовать скрытый тип как известный заранее, можно получить неверные ожидания о типах результата и потерять гарантию статической типизации.

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

Экзистенциал any P концептуально хранит пару: конкретное значение некоторого скрытого типа τ и таблицу соответствия протоколу. Для каждого экземпляра существует своя связь τ.Item, но имя Item не становится самостоятельным конкретным типом на уровне any P.

Обобщённая функция сохраняет эту связь:

protocol Box {
    associatedtype Value
    var value: Value { get }
}

struct IntBox: Box {
    let value: Int
}

func read<B: Box>(_ box: B) -> B.Value {
    box.value
}

let box = IntBox(value: 42)
let number: Int = read(box)
let erased: any Box = box

В read тип B.Value однозначно связан с конкретным B; для IntBox это Int. У erased такая связь существует внутри хранимого значения, но наружу конкретный тип не раскрывается. Доступ к члену с ассоциированным типом может быть разрешён с результатом, подвергнутым стиранию, но объявить переменную как any Box.Value нельзя.

Это не означает, что any P бесполезен. Он подходит для гетерогенных коллекций и динамической передачи объектов, когда вызывающему коду не требуется знать конкретный ассоциированный тип. Если связь между типами важна для дальнейших операций, следует использовать обобщения, type erasure с явно выбранным внешним типом или специальный enum.

Важно не смешивать any P и some P. some P скрывает конкретный тип от вызывающего кода, но сохраняет один фиксированный тип внутри результата или свойства. any P допускает разные конкретные типы, поэтому ассоциированный тип не может быть доступен как единый тип всей экзистенциальной переменной.

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

Сервис может принимать разные источники данных: один источник выдаёт User, другой — Order. Хранить их в массиве any DataSource удобно для регистрации и обхода, но общий код не может считать, что у всех источников одинаковый Element.

Рассматриваются варианты:

Обобщённый сервис сохраняет точную связь Source.Element и обеспечивает максимальную проверку типов, но не позволяет свободно смешивать источники разных типов.
Экзистенциал any DataSource позволяет хранить разные реализации вместе, однако операции, требующие конкретного элемента, становятся недоступными без дополнительного проектного решения.
Стирание типа к единому внешнему представлению, например к событию или результату с Any, упрощает композицию, но переносит часть проверок на время выполнения.
Enum с вариантами конкретных источников сохраняет контролируемый набор типов, но требует изменять enum при добавлении нового источника.

Если источники должны лишь регистрироваться и передаваться дальше, выбирают any DataSource. Если же над результатами выполняются типобезопасные операции, предпочтительнее обобщённый API или явно спроектированный type erasure с единым доменным результатом.

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

Можно ли привести any P к конкретной реализации, чтобы получить ассоциированный тип?

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

Почему обобщённая функция принимает any P, хотя внутри использует параметр типа?

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

Можно ли объявить массив значений протокола с разными ассоциированными типами?

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