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

Если обе ограниченные extensions протокола подходят конкретному типу и предоставляют разные реализации одного требования, Swift не должен выбирать реализацию по принципу «более подходящего» ограничения. Без собственной реализации требования соответствие становится неоднозначным и не компилируется. Надёжное решение — реализовать требование непосредственно в типе.

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

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

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

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

Предположим, associated type одновременно соответствует двум протоколам, а каждая ограниченная extension предлагает собственную реализацию одного требования. Если тип не объявляет метод сам, возникает несколько равноценных кандидатов.

Нельзя полагаться на порядок extensions или ожидать, что Swift автоматически выберет наиболее специализированную реализацию. Неоднозначность приводит к ошибке соответствия протоколу либо к невозможности однозначно сформировать witness table.

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

При объявлении соответствия Swift должен сопоставить каждое требование протокола с конкретной реализацией. Default implementation из extension может стать такой реализацией, но только если подходящий кандидат однозначен.

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

Собственная реализация требования в типе устраняет неоднозначность: она становится явным witness и имеет приоритет над default implementations из extensions. Если поведение действительно должно зависеть от комбинации ограничений, это условие лучше выразить в самом типе или вынести выбор в отдельный явно вызываемый generic-механизм.

protocol Renderable {
    associatedtype Format
    func render() -> String
}

extension Renderable where Format: TextFormat {
    func render() -> String { "текст" }
}

extension Renderable where Format: BinaryFormat {
    func render() -> String { "бинарные данные" }
}

struct Document: Renderable {
    typealias Format = TextAndBinary
    func render() -> String { "явный выбор" }
}

В примере TextAndBinary удовлетворяет обоим ограничениям, но Document задаёт собственный witness. Поэтому соответствие однозначно, независимо от порядка extensions.

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

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

Вариант с перестановкой extensions плох: порядок объявления не должен быть частью контракта и не устраняет концептуальную неоднозначность. Вариант с удалением одной реализации теряет специализированное поведение для части типов.

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

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

Всегда ли более узкое where-ограничение автоматически побеждает более широкое?

Нет. Для generic-перегрузок Swift может ранжировать кандидатов по специализации, но выбор witness для соответствия протоколу — отдельный механизм. Если несколько default implementations одновременно подходят одному требованию, безопасно считать выбор неоднозначным, а не рассчитывать на неявный приоритет.
Устраняет ли явная реализация метода в типе конфликт extensions?

Да, если это именно требование протокола с совпадающей сигнатурой. Метод типа используется как witness, поэтому Swift больше не должен выбирать между default implementations. Это отличается от метода, которого нет среди требований протокола: для него правила статической диспетчеризации через протокол могут быть другими.
Можно ли решить конфликт добавлением ещё одного ограничения в extension?

Можно только если ограничения действительно делают области применимости непересекающимися либо оставляют единственного кандидата. Само по себе добавление условия не гарантирует приоритет. Если тип продолжает удовлетворять нескольким extensions, наиболее ясное решение — предоставить явную реализацию в типе или изменить дизайн протокола так, чтобы выбор стратегии был выражен явно.