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

Потому что existentialное значение any P скрывает конкретный тип и его associatedtype. При обращении через existential Swift не всегда может статически доказать дополнительное условие из ограниченного extension, даже если фактический тип этому условию соответствует.

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

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

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

Проблема возникает при использовании такого протокола как existentialного типа: any P должен иметь единое представление, хотя конкретная реализация может выбирать собственный associatedtype. Swift скрывает этот тип, чтобы хранить разные реализации единообразно, но вместе с ним скрываются и некоторые доказательства generic-ограничений.

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

Рассмотрим протокол хранилища и дополнительный метод, доступный только для хранилищ, чьи значения соответствуют Equatable. Для конкретного типа IntBox это условие очевидно, но для переменной типа any Storage компилятор видит только факт соответствия Storage.

Если Swift разрешил бы такой вызов без статического доказательства, тело метода могло бы использовать операции Equatable для неизвестного типа. Это нарушило бы гарантию статической типизации.

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

Ограничение в extension проверяется относительно статического типа, с которым работает выражение. Для конкретного IntBox компилятор знает, что IntBox.Value равен Int, а Int соответствует Equatable. Для any Storage конкретный тип и его Value скрыты.

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

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

extension Storage where Value: Equatable {
    func containsSame(_ other: Value) -> Bool {
        value == other
    }
}

struct IntBox: Storage {
    let value: Int
}

let concrete = IntBox(value: 1)
let erased: any Storage = concrete

concrete.containsSame(1) // допустимо
// erased.containsSame(1) // ограничение Value: Equatable не доказано

Вызов через concrete допустим: его Value известен статически. Через erased Swift не может предположить, что скрытый Value поддерживает Equatable; фактическое содержимое existential-значения не заменяет статическое ограничение выражения.

Generic-код находится в другой ситуации. Если generic-функция объявляет условие S.Value: Equatable, компилятор получает это условие как доказанный факт для S и может вызвать метод ограниченного extension. Без такого ограничения generic-параметр также не сможет использовать метод, поскольку одного S: Storage недостаточно.

Это не связано с динамической диспетчеризацией метода. Ограниченный член extension сначала должен пройти проверку доступности по статическому типу; только после этого Swift выбирает способ его вызова. Type erasure удобен для хранения разнородных значений, но ценой потери части статической информации.

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

В приложении есть очередь событий, представленная разными реализациями Storage. Слой инфраструктуры хранит их как [any Storage], потому что конкретные типы значений различаются. Разработчик пытается вызвать на каждом элементе метод сравнения из ограниченного extension.

Вариант с прямым вызовом через any Storage прост, но не компилируется: тип Value неизвестен. Принудительное приведение к конкретному хранилищу делает код хрупким и уничтожает универсальность. Полное type erasure с замыканием сравнения сохраняет нужную операцию, но усложняет обёртку и требует заранее определить, какие операции будут доступны.

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

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

1. Достаточно ли фактического типа объекта для доступа к методу ограниченного extension?

Нет. При проверке вызова учитывается прежде всего статический тип выражения. Если значение объявлено как any Storage, компилятор не обязан использовать информацию о том, что в данный момент внутри находится IntBox.

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

Не всегда. Передача existential-значения в generic-код может открыть его скрытый конкретный тип, но это не означает автоматического доказательства произвольного условия над его associatedtype. Условие вроде S.Value: Equatable должно быть доступно компилятору в месте вызова; если оно не доказано для existentialного значения, вызов отклоняется.

3. Поможет ли объявление метода ограниченного extension требованием протокола?

Если требование объявлено в самом протоколе, оно становится частью контракта и доступно через existentialное значение как требование протокола. Однако его реализация всё равно не может безопасно использовать операции, для которых нет соответствующего ограничения. Поэтому перенос метода в протокол не отменяет необходимость корректно выразить ограничения над associatedtype.