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

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

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

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

Extensions отделяют основное объявление типа от дополнительного поведения и позволяют описывать соответствия протоколам вне тела типа. Это решает проблему интеграции независимых компонентов: приложение может адаптировать тип библиотеки к собственному протоколу без изменения исходного кода библиотеки.

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

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

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

Риски возникают на нескольких уровнях:

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

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

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

В extension можно объявить соответствие чужого типа собственному протоколу:

import Foundation

protocol CacheKey {
    var rawValue: String { get }
}

extension URL: CacheKey {
    var rawValue: String { absoluteString }
}

func load<S: CacheKey>(_ key: S) { }

Здесь URL принадлежит Foundation, а CacheKey — текущему модулю. После объявления соответствия URL принимается generic-кодом с ограничением S: CacheKey, а реализация требования хранится как часть соответствия, а не как случайный метод extension.

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

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

Если адаптация нужна только внутри небольшого приложения, ретроактивное соответствие может быть приемлемым. Для публичного API следует документировать его, проверять изменения зависимостей и учитывать диагностические требования конкретной версии Swift: современные toolchain могут требовать явно обозначать такие соответствия как ретроактивные.

Условное соответствие, например зависящее от соответствия Element другому протоколу, уменьшает область применимости, но не устраняет принципиальную проблему владения соответствием. Если другое условное или безусловное соответствие пересекается с ним, конфликт всё равно требует отдельного решения.

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

Команда добавила соответствие URL: CacheKey, чтобы использовать URL как ключ в общем кэше. Внутри приложения это было удобно: generic-код принимал любой CacheKey, а преобразование в строку находилось рядом с интеграцией Foundation.

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

Ретроактивное соответствие для URL — минимальный код и удобный вызов, но риск конфликта после обновления Foundation или другой зависимости.
Локальный адаптер — например, отдельный тип ключа, содержащий URL. Он безопаснее для публичного API, но требует явного создания адаптера.
Отказ от протокола — передавать в кэш строку напрямую. Это проще, но теряется типовая гарантия и единый контракт для других видов ключей.

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

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

Вопрос: Чем ретроактивное соответствие отличается от обычного extension-метода?

Extension-метод сам по себе добавляет член типа и не сообщает компилятору, что тип удовлетворяет требованиям протокола. Объявление соответствия формирует полноценную conformance-запись: именно её используют generic-ограничения, existential-значения и вызовы требований протокола.
Вопрос: Поможет ли отдельное пространство имён или вложенный тип избежать конфликта?

Да, если адаптация действительно выполняется через новый тип-обёртку. У обёртки другая пара «тип–протокол», поэтому она не конкурирует с соответствием исходного типа. Простое переименование extension или помещение вспомогательного метода в namespace не создаёт нового типа и проблему не решает.
Вопрос: Почему нельзя рассчитывать на выбор нужной реализации по месту вызова?

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