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

Swift не выбирает соответствие по порядку импорта или по месту вызова. Для пары «конкретный тип — протокол» ожидается одно однозначное соответствие; если два импортированных модуля объявляют конфликтующие соответствия, проект обычно не компилируется из-за неоднозначности или повторного соответствия.

Даже если реализации требований одинаковы, наличие двух независимых witness table для одной пары типов нарушает однозначность модели типов. Безопасное решение — оставить соответствие в одном модуле либо использовать адаптер или обёртку.

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

Протоколы в Swift поддерживают retroactive modeling: модуль может объявить соответствие уже существующего типа уже существующему протоколу через extension. Это удобно для интеграции библиотек, потому что исходный тип не обязан заранее знать о каждом внешнем протоколе.

Обратная сторона — разные модули могут попытаться описать одну и ту же связь. Поэтому соответствие рассматривается как свойство пары «тип — протокол», а не как локальная функция, которую можно выбирать отдельно в каждом месте вызова.

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

Предположим, библиотека A и библиотека B обе добавляют соответствие одного внешнего типа протоколу приложения. Реализации могут возвращать разные значения, иметь разные побочные эффекты или по-разному связывать associated type.

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

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

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

Упрощённая схема конфликта выглядит так:

// Модуль A
extension ExternalType: Describable {
    public func describe() -> String { "A" }
}

// Модуль B
extension ExternalType: Describable {
    public func describe() -> String { "B" }
}

При совместном использовании таких модулей Swift не должен молча выбирать «A» или «B». Конкретное диагностическое сообщение зависит от структуры модулей и места обнаружения конфликта, но полагаться на порядок импорта как на механизм разрешения нельзя.

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

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

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

Команда использует сторонний ExternalType. Модуль аналитики хочет соответствие CustomStringConvertible для логов, а модуль экспорта — другое соответствие для CSV. Добавлять оба соответствия самому ExternalType нельзя: они конфликтуют на уровне глобальной модели типов.

Вариант с двумя extension напрямую имеет минус: он приводит к конфликту и не позволяет выбирать поведение локально. Попытка управлять выбором импортами также ненадёжна и не меняет правила уникальности соответствия.

Выбранное решение — определить два адаптера, например AnalyticsValue и CSVValue, каждый из которых хранит ExternalType и имеет собственное соответствие. Это добавляет небольшие накладные расходы на оборачивание, зато делает поведение явным, локальным и совместимым с generic-ограничениями.

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

Можно ли решить конфликт приоритетом одного модуля?

Нет. Порядок импорта не является приоритетом для protocol conformance. Swift не предоставляет общего механизма выбора одного из двух соответствий для одной пары «тип — протокол».

Что изменится, если два соответствия предоставляют одинаковую реализацию?

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

Почему обёртка устраняет конфликт, если внутри хранится тот же тип?

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