impl Trait и dyn Trait

// разные типы в ветках — только так:
fn make(b: bool) -> Box<dyn Shape> {
    if b { Box::new(Circle) }
    else { Box::new(Square) }
}

Проверьте себя

Пять вопросов из банка по этой подтеме. Всего их 12, остальные разбираются в тренажёре.

1. #rs_dispatch1 / 5
   Когда стоит взять Box<dyn Trait> вместо дженерика с impl Trait?

   A)Когда в одной коллекции нужны значения разных конкретных типов

   B)Когда трейт содержит дженерик-методы

   C)Когда важна скорость: динамический вызов дешевле мономорфизации

   D)Когда типы известны на этапе компиляции и их немного

   показать ответ и разбор

   +A)Когда в одной коллекции нужны значения разных конкретных типов

   // разбор: Дженерик разворачивается в конкретный тип на каждый вызов — Vec<T> хранит однородные значения. Если в списке должны лежать разные реализации (обработчики, плагины, ошибки), нужен трейт-объект: Vec<Box<dyn Handler>>. Плата — динамические вызовы и потеря инлайнинга, зато меньше копий кода и быстрее сборка.

2. #rs_dispatch2 / 5
   Функция объявлена как fn make(b: bool) -> impl Shape и возвращает Circle в одной ветке и Square в другой. Что скажет компилятор?

   A)Соберёт: impl Trait для того и нужен, чтобы скрыть разные типы

   B)Соберёт с предупреждением о неявном приведении к трейт-объекту

   C)Ошибку: у impl Trait один конкретный тип, ветки несовместимы

   D)Ошибку: impl Trait запрещён в возвращаемой позиции

   показать ответ и разбор

   +C)Ошибку: у impl Trait один конкретный тип, ветки несовместимы

   // разбор: impl Trait в возврате означает «конкретный тип, который я не называю» — он один и тот же для всех путей выполнения. Разные типы в ветках дают E0308: if and else have incompatible types. Когда тип действительно должен различаться, возвращают Box<dyn Shape> и платят динамической диспетчеризацией.

3. #rs_dispatch3 / 5
   Трейт содержит fn parse<T: FromStr>(&self, s: &str) -> T. Почему &dyn этого трейта не собирается?

   A)Метод возвращает T по значению, а трейт-объект работает только со ссылками

   B)Дженерик-методы требуют, чтобы трейт был помечен как unsafe

   C)FromStr не реализован для всех типов, поэтому таблица методов неполна

   D)Трейт не dyn-совместим: под дженерик-метод нет одной записи в vtable

   показать ответ и разбор

   +D)Трейт не dyn-совместим: под дженерик-метод нет одной записи в vtable

   // разбор: vtable — таблица конкретных адресов, а дженерик-метод порождает по функции на каждый T: заранее их не перечислить. Такой трейт компилятор считает не dyn-совместимым (раньше говорили object safe) и роняет сборку с E0038. Лечится либо выносом метода за трейт, либо ограничением where Self: Sized, которое исключает его из таблицы.

4. #rs_dispatch4 / 5
   Насколько дорога динамическая диспетчеризация по сравнению со статической?

   A)Дороже в разы: каждый вызов ищет метод по имени в таблице

   B)Сам вызов дёшев, теряются инлайнинг и оптимизации вокруг

   C)Одинаково: компилятор разворачивает dyn в статические вызовы

   D)Дороже только при первом вызове, дальше адрес кэшируется

   показать ответ и разбор

   +B)Сам вызов дёшев, теряются инлайнинг и оптимизации вокруг

   // разбор: Косвенный вызов через vtable — это чтение адреса и переход, единицы тактов. Настоящая цена в другом: тело метода неизвестно на месте вызова, поэтому нет инлайнинга, а с ним не работают развёртка циклов, векторизация и свёртка констант. В горячем цикле разница заметна, в обработчике запроса — теряется на фоне ввода-вывода.

5. #rs_dispatch5 / 5
   Что называют статической диспетчеризацией?

   A)Разрешение имён методов по порядку подключённых модулей в текущей области видимости

   B)Выбор реализации по таблице методов, которую компилятор строит один раз для всех типов сразу

   C)Выбор реализации на этапе компиляции: адрес метода известен и вызов можно встроить

   D)Кэширование адреса метода после первого вызова, чтобы дальше идти по короткому пути

   показать ответ и разбор

   +C)Выбор реализации на этапе компиляции: адрес метода известен и вызов можно встроить

   // разбор: Дженерик разворачивается под конкретный тип, поэтому вызываемая функция известна прямо в точке вызова: компилятор подставляет адрес, часто встраивает тело и оптимизирует всё вокруг. Это и есть zero-cost abstraction — абстракция обошлась в ноль инструкций. Противоположность — динамическая диспетчеризация через dyn, где адрес читается из таблицы в рантайме.