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

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

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

Модель протоколов Swift предполагает единую конформность конкретного типа к конкретному протоколу. Это позволяет однозначно определить требования протокола и связанные с ними associated types, а во время выполнения использовать единственный набор witness-таблиц для этой пары типов.

Условные конформности решают другую задачу: generic-тип может соответствовать протоколу только при выполнении ограничения его параметра. Однако условие не превращает конформность в перегружаемую функцию — для каждой пары тип–протокол всё равно должна существовать одна согласованная конформность.

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

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

Тогда становятся неоднозначными associated types, реализации требований протокола и результат generic-кода. Даже если автор считает условия взаимоисключающими, Swift не использует условные конформности как систему приоритетов и не выбирает «более подходящую» реализацию.

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

Компилятор проверяет условные конформности на конфликт для одной пары generic-типа и протокола. Если объявления могут описывать одну и ту же специализацию, они считаются конфликтующими; в общем случае Swift не разрешает несколько таких конформностей, чтобы сохранить однозначность модели.

Например, следующий принципиальный вариант недопустим:

protocol EncodableView {
    associatedtype Format
}

struct Box<T> {}

extension Box: EncodableView where T: BinaryInteger {
    typealias Format = String
}

extension Box: EncodableView where T: FloatingPoint {
    typealias Format = Double
}

Тип-параметр теоретически может удовлетворять обоим ограничениям, а сама пара Box<T> — EncodableView получает два кандидата на конформность. Swift не пытается разрешить это через перегрузку и сообщает о конфликте соответствий.

Надёжное решение — оставить одну конформность с единым набором ограничений и единым associatedtype, либо разделить варианты на разные типы-обёртки. В первом случае поведение проще использовать, но общий интерфейс может оказаться менее специализированным. Обёртки дают точный контроль над семантикой, зато увеличивают количество типов и преобразований.

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

Важно отличать конфликт конформностей от перегрузки функций. Несколько функций могут различаться ограничениями и выбираться по контексту, тогда как конформность типа к протоколу должна быть единственной и стабильной для данного набора условий.

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

В библиотеке есть универсальный контейнер Box<T>, который должен предоставлять протокол форматированного представления. Для целых значений команда хотела использовать строковый формат, а для вещественных — числовой. Первым вариантом стали две условные конформности одного Box к одному протоколу.

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

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

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

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

Может ли Swift выбрать более специфичную условную конформность, если одна включает другую?

Нет. Условные конформности не образуют иерархию приоритетов. Если для типа потенциально подходят две конформности к одному протоколу, нельзя рассчитывать, что будет выбрана более узкая; модель требует устранить конкуренцию на уровне объявлений.

Можно ли избежать конфликта, задав разный associatedtype в каждой конформности?

Нет. Разный associatedtype не устраняет проблему, а подчёркивает её: для одной и той же пары тип–протокол появились бы разные ответы на один и тот же контракт. Конкретная специализация должна иметь одно согласованное значение каждого associated type.

Помогут ли взаимоисключающие ограничения, если автор может доказать их логически?

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