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

Rust выполняет trait upcasting coercion: объект dyn Subtrait можно автоматически преобразовать в объект dyn Supertrait, если субтрейt явно объявлен через супер-трейт. Преобразование безопасно, потому что любой объект субтрейта гарантированно поддерживает контракт супер-трейта.

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

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

Трейтовые объекты позволяют отделить код, использующий поведение, от конкретного типа реализации. На границе API это особенно важно: функция может зависеть только от минимального базового контракта, даже если вызывающий код располагает более специализированным объектом.

Trait upcasting coercion решает задачу перехода от специализированного трейтового интерфейса к обобщенному без ручных адаптеров и без потери безопасности статической типизации. Такой переход является расширением возможностей полиморфизма через dyn Trait, а не альтернативой generic-коду.

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

Пусть библиотечная функция умеет работать только с базовым трейтом Readable, а конкретный объект предоставляется как dyn LoggedReadable. Если между трейтами объявлена связь супер-трейта, объект специализированного интерфейса логически уже содержит требуемые возможности.

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

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

Связь задается объявлением субтрейта через супер-трейт: LoggedReadable: Readable. После этого &dyn LoggedReadable может быть передан туда, где ожидается &dyn Readable. Аналогичная coercion применима к поддерживаемым указательным формам трейтовых объектов, например к Box<dyn LoggedReadable> при ожидаемом Box<dyn Readable>.

trait Readable {
    fn read(&self) -> String;
}

trait LoggedReadable: Readable {
    fn log(&self);
}

fn consume(value: &dyn Readable) {
    println!("{}", value.read());
}

struct File;
impl Readable for File { fn read(&self) -> String { "data".into() } }
impl LoggedReadable for File { fn log(&self) {} }

fn main() {
    let value: &dyn LoggedReadable = &File;
    consume(value);
}

Вызов consume(value) использует upcasting из &dyn LoggedReadable в &dyn Readable. Трейтовый объект содержит указатель на данные и метаданные; компилятор подбирает представление, соответствующее супер-трейту. На детали расположения vtable нельзя опираться в unsafe-коде как на публичную гарантию ABI.

Upcasting не делает обратное преобразование. Из &dyn Readable нельзя безопасно автоматически получить &dyn LoggedReadable, потому что исходный объект мог поддерживать только базовый трейт. Для обратной проверки обычно применяют специальный метод API, Any с ограничениями или явную модель типов.

Оба трейта должны быть пригодны для использования как dyn Trait. Если субтрейt содержит методы или требования, несовместимые с трейтовым объектом, сам объект субтрейта создать нельзя, поэтому upcasting в таком виде также невозможен.

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

В библиотеке аудита есть Readable с операцией чтения и LoggedReadable, добавляющий журналирование. Функция сериализации использует только чтение, поэтому ее параметр объявлен как &dyn Readable, хотя вызывающий слой хранит объекты как &dyn LoggedReadable.

Можно было изменить функцию на &dyn LoggedReadable, но это увеличило бы требования API и исключило бы обычные Readable-объекты. Можно было сделать функцию generic с bound T: Readable + ?Sized; это сохраняет статическую универсальность, но не требуется, если функции нужен именно единый динамический интерфейс.

Выбран upcasting к &dyn Readable: API зависит от минимального контракта, вызов остается безопасным, а дополнительное поведение субтрейта не навязывается потребителю. Если же функция должна быть высокопроизводительной для известных конкретных типов, предпочтительнее generic-параметр, поскольку он допускает статическую диспетчеризацию.

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

Достаточно ли совпадения методов двух трейтов для upcasting?

Нет. Rust использует номинальную, а не структурную связь трейтов. Даже если Specialized содержит все методы Readable с совместимыми сигнатурами, преобразование невозможно без явного объявления trait Specialized: Readable.

Это предотвращает неоднозначность: одинаковые по форме методы не доказывают, что авторы трейтов согласовали единый контракт, семантику и совместимость изменений. Иерархия супер-трейтов является частью публичного API.
Можно ли из объекта супер-трейта автоматически получить объект субтрейта?

Нет, это обратное, или downcasting-преобразование. Тип dyn Readable не сообщает, был ли исходный конкретный тип также LoggedReadable; информация о дополнительном поведении могла быть недоступна после стирания типа.

Безопасный downcasting требует отдельного механизма: например, трейта, предоставляющего проверку через Any, либо метода, который автор API явно спроектировал для такой проверки. Простое утверждение о наличии субтрейта было бы небезопасным.
Происходит ли upcasting внутри любой generic-функции автоматически?

Не обязательно. В функции с параметром T: Readable + ?Sized аргумент &dyn LoggedReadable обычно сохраняет конкретное значение T = dyn LoggedReadable; функции не нужно превращать его в dyn Readable, поскольку dyn LoggedReadable само удовлетворяет bound Readable.

Coercion требуется, когда контекст ожидает именно &dyn Readable, например параметр функции или явная аннотация типа. Это отличается от generic-подстановки: bounds проверяют допустимость типа, а coercion меняет представление значения в конкретной позиции вызова.