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

Ошибка возникает потому, что переменные имеют статический тип Error, а протокол Error не наследует Equatable. Соответствие конкретного типа NetworkError протоколу Equatable не добавляет оператор == самому existential-типу any Error.

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

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

Модель throws использует общий протокол Error, чтобы функция могла передавать наверх ошибки разных конкретных типов без объявления отдельного универсального параметра ошибки. Это упрощает распространение ошибок через несколько уровней вызовов.

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

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

В коде фактическое значение создано как NetworkError.timeout, но переменные объявлены как Error. Компилятор проверяет доступность == по статическим типам операндов, поэтому он не может предположить, что любые два значения Error корректно сравнимы.

Нельзя решать эту задачу сравнением localizedDescription: текст предназначен для отображения и может зависеть от локали, формулировки или реализации. Такое сравнение хрупко и не является проверкой семантического типа ошибки.

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

Нужно восстановить конкретный тип до сравнения:

enum NetworkError: Error, Equatable {
    case timeout
    case refused
}

let actual: Error = NetworkError.timeout

if let networkError = actual as? NetworkError,
   networkError == .timeout {
    print("тайм-аут")
}

Оператор as? выполняет проверку динамического типа и возвращает NetworkError?. После успешного извлечения переменная имеет конкретный тип NetworkError, для которого доступно синтезированное соответствие Equatable.

Для обработки ошибки обычно лучше использовать catch с приведением типа или сопоставлением с образцом. Это одновременно проверяет тип и позволяет извлечь associated value, если он есть.

Соответствие Equatable автоматически синтезируется для перечисления, только если все его associated values сами поддерживают Equatable. Если это невозможно или равенство должно иметь особую семантику, его реализуют вручную.

Следует учитывать компромисс: равенство ошибок — это дополнительный контракт доменной модели, а не свойство всех ошибок Swift. Для большинства обработчиков достаточно проверить категорию ошибки и её данные, не требуя полного равенства объектов.

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

Сервис загрузки возвращает Error, а ViewModel должна отдельно обработать тайм-аут и остальные сбои. Вариант с localizedDescription прост, но ломается при изменении текста и локализации. Сравнение двух значений типа Error также не компилируется и не могло бы быть универсально корректным: разные типы ошибок не обязаны иметь смысл равенства.

Выбранное решение — привести ошибку к доменному типу и разобрать его случаи:

enum LoadError: Error {
    case timeout(seconds: Int)
    case unauthorized
}

func message(for error: Error) -> String {
    guard let error = error as? LoadError else {
        return "Неизвестная ошибка"
    }

    switch error {
    case .timeout(let seconds):
        return "Превышено ожидание: \(seconds) с"
    case .unauthorized:
        return "Требуется авторизация"
    }
}

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

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

Достаточно ли написать enum NetworkError: Error, Equatable, чтобы сравнивать любые значения типа Error?

Нет. Это добавляет Equatable только NetworkError. Значение, статически объявленное как Error, по-прежнему не предоставляет оператор ==, потому что сам протокол Error не требует Equatable.

Нужно хранить значение как NetworkError, привести его из any Error или обработать через catch let error as NetworkError.

Почему проверка типа предпочтительнее сравнения текстового описания ошибки?

Тип и associated values являются частью программного контракта и могут использоваться для ветвления логики. Текст ошибки предназначен для человека, может быть локализован, изменён или сформирован внешней библиотекой.

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

Когда для ошибки лучше использовать сопоставление с образцом, а не Equatable?

Сопоставление с образцом подходит, когда нужно проверить только конкретный случай или условие над associated value. Например, можно обработать .timeout с ожиданием больше заданного порога, не сравнивая всю структуру ошибки целиком.

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