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

Через обобщённый параметр Rust обычно применяет статическую диспетчеризацию: компилятор создаёт специализированную версию функции для каждого фактического типа и заранее разрешает вызов метода. Через объект трейта dyn Trait применяется динамическая диспетчеризация: конкретный метод выбирается во время выполнения через таблицу виртуальных методов.

Статическая диспетчеризация обычно даёт возможность инлайнинга и не требует виртуального вызова, но увеличивает размер бинарного файла и ограничивает однородность коллекций. Динамическая диспетчеризация позволяет работать с разными реализациями через единый интерфейс, однако добавляет косвенный вызов и требует соблюдения ограничений совместимости трейта с объектами.

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

В системном программировании часто нужно одновременно получить абстракцию интерфейса и предсказуемые накладные расходы. Generics позволяют описывать алгоритм один раз, сохраняя специализацию под конкретные типы, а trait objects позволяют выбирать реализацию во время выполнения.

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

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

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

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

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

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

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

Минимальное сравнение выглядит так:

trait Render {
    fn render(&self) -> String;
}

fn static_render<T: Render>(value: &T) -> String {
    value.render()
}

fn dynamic_render(value: &dyn Render) -> String {
    value.render()
}

В static_render параметр T известен после мономорфизации, а в dynamic_render вызов идёт через объект трейта. Ссылка &dyn Render не владеет значением; аналогично можно использовать другие формы указателей, например Box<dyn Render>, если требуется владение объектом.

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

Для dyn Trait действуют правила dyn-совместимости. Методы, требующие произвольного Self, имеющие неподходящие обобщённые параметры или возвращающие Self без специальных ограничений, могут сделать трейт непригодным для использования как объект трейта. Это ограничение не означает, что такой трейт нельзя реализовать или использовать со статическими обобщениями.

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

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

Можно сделать отдельную статическую цепочку обработчиков для каждого типа. Плюсы — отсутствие виртуального вызова и больше возможностей оптимизации; минусы — сложный API и невозможность простой коллекции разнородных обработчиков.

Другой вариант — хранить обработчики за указателями на объект трейта. Он добавляет косвенный вызов и требует, чтобы интерфейс был dyn-совместимым, зато позволяет единообразно хранить и вызывать разные реализации.

Для диспетчера событий выбирается объект трейта: гибкость контейнера важнее небольшой стоимости вызова, а число обработчиков меняется во время работы программы. В результате добавление новой реализации не требует изменения типа коллекции или создания отдельной статической цепочки.

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

Всегда ли обобщённый параметр означает динамическую диспетчеризацию?

Нет. Ограничение трейта у параметра типа, например концептуально T: Trait, обычно приводит к статической диспетчеризации после мономорфизации. Динамическая диспетчеризация появляется, когда тип явно стирается до формы dyn Trait или помещается за указатель на такой объект.

Почему объект трейта нельзя использовать для любого трейта?

Объект трейта должен иметь однозначный способ вызвать методы, не зная конкретного типа. Поэтому методы, зависящие от размера или конкретного значения Self, а также некоторые обобщённые методы не подходят для виртуальной таблицы в общем случае. Такие методы можно иногда ограничить Self: Sized, но тогда они не будут доступны через объект трейта.

Обязательно ли статическая диспетчеризация быстрее динамической?

Нет, это не абсолютное правило. Статический вызов устраняет стоимость виртуального выбора и может облегчить оптимизацию, но мономорфизация способна увеличить бинарный файл и ухудшить использование кэша инструкций. Динамический вызов добавляет косвенность, однако иногда уменьшает дублирование кода; окончательный выбор зависит от горячести участка и требований к архитектуре.