Разберите ошибку компиляции: почему Rust считает реализации пересекающимися, хотя Token сейчас не реализует Copy?
trait Marker {}
impl<T: Copy> Marker for T {}
struct Token;
impl Marker for Token {}
Реализации пересекаются, потому что Token потенциально может реализовать Copy. Обобщённая реализация тогда применялась бы к Token, одновременно с явной реализацией Marker, поэтому Rust отклоняет код по правилам coherence.
Текущее отсутствие реализации Copy не спасает ситуацию: Rust должен гарантировать отсутствие неоднозначности и в будущих допустимых версиях программы.
Правила coherence появились как часть модели Rust, в которой для каждой пары типа и трейта должен быть однозначный источник реализации. Это предотвращает ситуацию, когда один и тот же вызов метода начинает выбирать разные реализации после добавления нового трейта или реализации в другом crate.
Связанный с этим orphan rule ограничивает, кто может добавлять реализации для чужих трейтов и типов. Вместе эти правила сохраняют предсказуемость статической диспетчеризации и позволяют библиотекам развиваться без скрытых конфликтов реализаций.
Шаблон impl<T: Copy> Marker for T означает: любой тип, удовлетворяющий Copy, получает Marker. Token является локальным типом и в принципе может получить Copy, например после изменения его объявления или добавления допустимой реализации.
Если Rust разрешил бы явную реализацию уже сейчас, то после появления impl Copy for Token существовали бы две реализации Marker for Token. Компилятор не мог бы однозначно определить, какую из них использовать.
При проверке пересечения Rust рассматривает не только текущий набор доказанных bounds, но и возможность существования типа, удовлетворяющего всем ограничениям обеих реализаций. Для Token и явной реализации условие выполняется напрямую, а для blanket-реализации достаточно потенциального условия Token: Copy.
Поэтому эти две реализации считаются пересекающимися:
Проверка не является выбором «более специфичной» реализации. Rust не использует стабильную специализацию, которая позволяла бы автоматически предпочесть impl Marker for Token общей реализации. Наличие bound в blanket-реализации также не превращает её в реализацию, проверяемую только в момент вызова.
Обычно проблему решают изменением формы API:
impl<T: Copy> Marker for Wrapper<T>;Нельзя надёжно решить проблему ожиданием, что Token «никогда не станет Copy». Это не выражено в положительных bounds. Отрицательные bounds вида T: !Copy для обычного использования traits не являются общим стабильным механизмом, а специализация не должна рассматриваться как доступное по умолчанию решение.
Библиотека хотела автоматически помечать все копируемые значения трейтом CacheKey, но для UserId требовалась отдельная реализация с особой семантикой.
Первый вариант — blanket-реализация для всех Copy и явная реализация для UserId. Он не компилируется: UserId может стать Copy, и реализации пересекаются.
Второй вариант — специализация. Она позволила бы описать общее и частное правило, но не является стабильным универсальным решением Rust и добавляет сложность выбора реализации.
Выбранный вариант — новый тип с отдельной формой реализации, например CacheKeyWrapper<T>, для которого общее правило не пересекается с реализацией UserId. Это сохраняет однозначность coherence, явно показывает особую семантику в API и не зависит от будущего добавления Copy.
Достаточно ли того, что Token в текущем коде не реализует Copy?
Нет. Проверка coherence анализирует потенциальное пересечение реализаций, а не только фактически доступные реализации в текущей точке компиляции. Если тип может законно удовлетворить bound blanket-реализации, конфликт уже считается возможным.
Почему компилятор не может выбрать явную реализацию как более специфичную?
В стабильном Rust нет общего механизма специализации, который разрешал бы такие пересечения и задавал приоритет реализаций. Автоматический выбор «явная реализация важнее общей» сделал бы поведение зависимым от набора impl-блоков и усложнил бы совместимость библиотек. Поэтому потенциальное пересечение запрещается целиком.
Как сохранить общее поведение только для структурно отличимых типов?
Нужно изменить множество типов, к которым применяется blanket-реализация, чтобы оно не включало специальный случай. Например, impl<T: Copy> Marker for Wrapper<T> применяется к Wrapper<T>, а не ко всем T; реализация Marker for Token тогда не пересекается с ним. Другой вариант — использовать отдельный marker-трейт, реализации которого контролирует библиотека, но он должен быть спроектирован так, чтобы общий и специальный impl-блоки всё равно не описывали одну и ту же пару типа и трейта.