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

Правило сиротских реализаций запрещает реализовать внешний трейт для внешнего типа: ни трейт, ни тип, для которого пишется реализация, не принадлежат текущему crate. Это поддерживает глобальную согласованность: разные crates не смогут независимо добавить конфликтующие реализации одного и того же трейта для одного типа.

Обычно проблему решают через newtype — локальную обёртку над внешним типом. Обёртка становится новым локальным типом, для которого разрешена реализация внешнего трейта.

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

Rust допускает раздельную компиляцию crates, поэтому компилятор не может рассчитывать на централизованный список всех будущих реализаций. Если бы любой crate мог реализовать любой внешний трейт для любого внешнего типа, подключение дополнительной зависимости могло бы внезапно создать неоднозначность.

Правила orphan и coherence заранее ограничивают такие реализации. Благодаря этому выбор реализации остаётся предсказуемым, а авторы crates могут добавлять новые реализации, не ломая чужой код из-за скрытого конфликта.

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

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

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

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

Для реализации действует базовое правило: либо трейt локален, либо реализуемый тип локален. Локальным считается тип, определённый в текущем crate; одного ограничения на параметр типа недостаточно.

Например, Display является внешним трейтом, но Report — локальный тип, поэтому такая реализация разрешена:

use std::fmt::{self, Write};

struct Report(Vec<String>);

impl fmt::Display for Report {
    fn fmt(&self, f: &mut fmt::Formatter<'_>) -> fmt::Result {
        write!(f, "{}", self.0.join(", "))
    }
}

// Нельзя: и Display, и Vec<String> внешние.
// impl fmt::Display for Vec<String> { ... }

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

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

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

Главный компромисс таков: orphan rules ограничивают расширяемость чужих типов, зато сохраняют однозначность метода и стабильность композиции crates. Newtype возвращает контроль разработчику, но создаёт новый тип, который нужно явно интегрировать с остальным API.

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

Команда использует внешний тип конфигурации и хочет дать ему формат вывода через внешний трейт Display.

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

Реализовать Display непосредственно для внешнего типа. Это самый простой API, но Rust запрещает такой impl по правилу сирот.
Создать локальный newtype. Это разрешено и даёт полный контроль над форматированием, но требует явного оборачивания значения и, возможно, делегирования нужных операций.
Добавить собственный локальный трейт форматирования. Это не нарушает orphan rules, но код, ожидающий именно Display, не сможет использовать новый трейт без адаптера.

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

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

Достаточно ли bound на локальный трейт, чтобы разрешить реализацию внешнего трейта для параметра типа?

Нет. Реализация вида «внешний трейт для любого T, если T реализует локальный трейт» всё равно нарушает orphan rule: Self — это параметр типа, а локальный трейт в bound не делает сам T локальным типом. Ограничение задаёт логическое условие применимости, но не предоставляет право владения типом.

Можно ли реализовать внешний трейт для внешнего типа, если такая реализация точно не пересекается с существующими?

Нет. Отсутствие текущего пересечения недостаточно: orphan rule проверяет структуру реализации, а не только известные на данный момент конфликты. Это заранее предотвращает появление конфликтов после подключения другой зависимости или добавления новых реализаций.

Почему type alias обычно не помогает обойти orphan rule?

Псевдоним типа не создаёт новый тип, а только даёт существующему типу другое имя. Если псевдоним указывает на внешний тип, реализация для него по-прежнему считается реализацией для исходного внешнего типа и остаётся запрещённой. Для обхода нужен именно новый тип, например struct Wrapper(ExternalType), а не type Wrapper = ExternalType.