Orphan rule и newtype в Rust

Почему нельзя чужое для чужого

Представь, что два независимых крейта реализовали Display для Vec<u8> по-своему. Пока они живут порознь - всё в порядке, но как только оба попали в одну программу, выбор становится неразрешимым, и семантика кода начинает зависеть от списка зависимостей.

Orphan rule закрывает этот сценарий: хотя бы одна сторона - трейт или тип - должна принадлежать вашему крейту. Иначе E0117. Это цена за свойство, которое называют согласованностью: для пары трейт-тип реализация во всей программе одна.

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

orphan rule

запрет реализовывать чужой трейт для чужого типа

coherence

не более одной реализации на пару трейт-тип

Newtype: обход и типобезопасность

Стандартный обход - обернуть чужой тип в свой: struct Hex(Vec<u8>), и Display пишется уже для Hex. Кортежная структура с одним полем имеет ровно ту же раскладку, что и поле, поэтому в рантайме обёртки нет - только на уровне типов.

Тот же приём используют и без всякого orphan rule, ради безопасности: Meters(f64) и Seconds(f64) перестают складываться друг с другом, а функция, ждущая UserId, не примет случайный i64. Ошибки такого рода ловятся компилятором и стоят ноль.

// Минус один: обёртка не наследует методы внутреннего типа. Нужные пробрасывают вручную или реализуют Deref, но с Deref стоит быть осторожным, он размывает границу абстракции.

struct Hex(Vec<u8>);
impl std::fmt::Display for Hex { /* .. */ }

newtype

обёртка из одного поля с собственным типом

нулевая стоимость

раскладка обёртки совпадает с раскладкой поля

Blanket impl и отсутствие специализации

Сплошная реализация раздаёт поведение целому семейству: impl<T: Display> ToString for T в стандартной библиотеке - именно она. Побочный эффект в том, что после такого impl добавить частный случай для конкретного типа уже нельзя: компилятор увидит перекрытие.

Отсюда частый вопрос: почему в стабильном Rust нет специализации, когда более конкретная реализация побеждает общую. Проблема не техническая, а в согласованности: наивная специализация позволяет поведению зависеть от лайфтаймов, которые стираются, то есть от того, чего в рантайме уже нет. Фича живёт под флагом min_specialization и используется внутри std, где ограничения контролируются вручную.

// Ещё одна полезная сплошная реализация: из From<A> for B автоматически следует Into<B> for A. Поэтому в сигнатурах просят Into, а реализуют всегда From.

blanket impl

реализация трейта сразу для всех подходящих типов

специализация

приоритет более конкретной реализации; в стабильном Rust отсутствует

Как отвечать: «Почему нельзя реализовать Display для Vec<u8> и что делать?»

Мешает orphan rule: и трейт, и тип чужие, а язык гарантирует, что на пару трейт-тип во всей программе есть не больше одной реализации. Если бы два крейта дали Vec<u8> разные Display, при сборке вместе выбор стал бы неразрешимым. Обхожу это через newtype: заворачиваю в свою структуру Hex(Vec<u8>) и пишу Display уже для неё. В рантайме такая обёртка бесплатна - у кортежной структуры с одним полем та же раскладка, что у поля. Заодно она часто полезна сама по себе: типобезопасность вроде Meters и Seconds, которые не должны складываться.

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

На чём валятся

• −Считают newtype дорогой обёрткой - в рантайме её нет.
• −Не могут объяснить, зачем нужен orphan rule, и говорят «просто такое правило».
• −Пишут blanket impl, а потом не могут добавить частный случай для одного типа.
• −Ждут, что специализация работает, как перегрузка в C++.
• −Реализуют Into вместо From и лишаются автоматического второго направления.