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

Потому что any Equatable — это не конкретный тип, соответствующий Equatable, а контейнер с неизвестным конкретным типом внутри. Оператор равенства требует сравнивать два значения одного и того же конкретного типа, а статический тип any Equatable этого не гарантирует.

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

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

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

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

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

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

У двух значений типа any Equatable конкретные типы могут различаться. Сравнение числа со строкой не имеет универсально определённого смысла, поэтому Swift не выбирает такое поведение автоматически и не пытается неявно привести значения к Any или вызвать сравнение динамически.

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

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

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

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

struct AnyEquatableValue {
    private let value: Any
    private let equals: (Any) -> Bool

    init<T: Equatable>(_ value: T) {
        self.value = value
        self.equals = { other in
            guard let other = other as? T else { return false }
            return value == other
        }
    }

    static func == (lhs: Self, rhs: Self) -> Bool {
        lhs.equals(rhs.value)
    }
}

let first = AnyEquatableValue(10)
let second = AnyEquatableValue(10)
print(first == second)

В этом примере замыкание, созданное для конкретного T, сначала проверяет динамический тип второго значения. Если типы различаются, результатом становится false; если совпадают, вызывается исходная реализация Equatable.

У такого решения есть компромиссы: появляется дополнительная обёртка, проверка типа выполняется во время выполнения, а часть статических гарантий теряется. Если набор типов заранее известен, иногда лучше использовать перечисление с отдельными случаями или обобщённую функцию с параметром T: Equatable.

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

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

Представим кэш значений, полученных из разных источников. В нём могут находиться числа, строки и идентификаторы, каждый из которых соответствует Equatable, но сам кэш должен хранить их единообразно.

Первый вариант — хранить значения как Any. Это даёт максимальную гибкость, но полностью убирает возможность типобезопасного сравнения. Второй вариант — хранить any Equatable; он документирует требование к значениям, но прямое равенство всё равно недоступно из-за неизвестного конкретного типа.

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

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

Является ли any Equatable самим типом Equatable?

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

Можно ли сравнивать два значения any Equatable, если известно, что они пришли из одного источника?

Для компилятора этого недостаточно, если информация не выражена в типах. Нужно сохранить общий конкретный тип через обобщённый параметр T: Equatable либо самостоятельно проверить динамические типы и выполнить типо-стирание. Внешнее логическое предположение разработчика не заменяет статическую гарантию Swift.

Почему AnyHashable можно использовать как ключ словаря, а any Equatable нельзя напрямую сравнивать?

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