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

Нет, одного ограничения Equatable недостаточно. Оно гарантирует, что каждый параметр можно сравнивать со значением того же конкретного типа, но не утверждает, что два параметра имеют один и тот же тип.

Чтобы сравнение было допустимо, нужно связать параметры ограничением same-type — например, потребовать равенство типов. Либо следует объявить один generic-параметр и использовать его для обоих аргументов.

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

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

Такой подход предотвращает неявные предположения: два типа могут соответствовать одному протоколу, оставаясь полностью разными типами. Связь между ними должна быть выражена отдельным ограничением.

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

Пусть один аргумент имеет тип Int, а другой — String. Оба типа соответствуют Equatable, но оператор равенства в Swift предназначен для сравнения значений одного конкретного типа.

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

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

У Equatable операция равенства концептуально связана с одним типом: значение сравнивается с другим значением того же типа. Ограничение T: Equatable даёт право сравнивать два значения типа T, а U: Equatable — два значения типа U.

Эти ограничения независимы. Они не означают T == U, поэтому операция между значениями типов T и U не гарантирована.

func sameValue<T: Equatable>(_ lhs: T, _ rhs: T) -> Bool {
    lhs == rhs
}

func sameValue<T, U>(_ lhs: T, _ rhs: U) -> Bool
where T: Equatable, U: Equatable, T == U {
    lhs == rhs
}

В первом варианте оба аргумента используют один параметр T, поэтому их типы совпадают. Во втором варианте параметры остаются раздельными, но ограничение T == U явно устанавливает между ними отношение одного типа.

У same-type constraint есть практическая цена: функция больше не принимает действительно разные типы. Если API должен сравнивать значения разных типов, нужно определить отдельную семантику сравнения — например, сравнивать их общие идентификаторы или заранее преобразовывать к единому доменному типу.

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

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

Рассматривались варианты:

оставить два независимых параметра — это сохраняет гибкость API, но не даёт корректного общего сравнения;
заменить их одним параметром — просто и безопасно, если источники обязаны содержать элементы одного типа;
добавить T == U — сохраняет отдельные имена параметров и явно фиксирует требуемую связь;
ввести преобразование к общему ключу — подходит для осмысленного межтипового сравнения, но требует определить правила преобразования и возможные потери информации.

Если бизнес-правило требует сравнивать элементы только одного типа, выбран вариант с одним параметром или same-type constraint. Это делает контракт API проверяемым на этапе компиляции и не маскирует ошибку под потенциально сомнительное межтиповое сравнение.

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

Означает ли соответствие двух типов одному протоколу, что эти типы одинаковы?

Нет. Ограничения T: Equatable и U: Equatable описывают две отдельные гарантии. Например, Int и String оба могут быть сравнимыми со значениями собственного типа, но это не делает их взаимозаменяемыми и не разрешает сравнение Int со String.
Что именно меняет добавление ограничения T == U?

Оно устанавливает однотипность параметров на уровне generic-контракта. После этого компилятор рассматривает T и U как один и тот же тип, поэтому операции, требующие одинаковых типов операндов, становятся допустимыми. Это не преобразует один тип в другой во время выполнения, а сужает множество допустимых подстановок ещё при проверке типов.
Можно ли решить задачу, заменив параметры на any Equatable?

Обычно нет. any Equatable скрывает конкретный тип за existential-значением, но не гарантирует, что два таких значения содержат один и тот же конкретный тип. Кроме того, сам existential не предоставляет универсальное межтиповое равенство: реализация Equatable каждого конкретного типа рассчитана на сравнение со значением того же типа. Для безопасного сравнения нужно сохранить связь типов через generics либо явно определить правила сравнения после проверки или нормализации типов.