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

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

Исключение — если обобщённый метод ограничен where Self: Sized. Тогда трейт может оставаться объектно-совместимым, но этот метод нельзя вызвать через dyn Trait; он доступен только для конкретного типа, размер которого известен компилятору.

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

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

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

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

Рассмотрим трейт, метод которого принимает произвольный тип T. Конкретный вызов может потребовать одну реализацию метода для String, другую для u64, третью для пользовательского типа и так далее.

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

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

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

Поэтому метод с собственным параметром типа несовместим с обычным трейтовым объектом. Ограничение Self: Sized меняет ситуацию:

trait Render {
    fn render<T: std::fmt::Display>(&self, value: T)
    where
        Self: Sized;
}

struct Html;

impl Render for Html {
    fn render<T: std::fmt::Display>(&self, value: T)
    where
        Self: Sized,
    {
        println!("{value}");
    }
}

fn use_object(renderer: &dyn Render) {
    // renderer.render(42); // ошибка: метод недоступен для dyn Render
}

Здесь сам трейт можно использовать как dyn Render, потому что проблемный метод исключён из интерфейса трейтового объекта. Однако это не делает метод динамически вызываемым: его можно вызвать через Html, но нельзя через &dyn Render.

Практическое решение зависит от цели. Если нужен динамический вызов, обычно заменяют обобщённый параметр на конкретный тип, например &str или &dyn Display, либо выносят обобщённую вспомогательную операцию в отдельную свободную функцию. Первый вариант проще для vtable, но может уменьшить универсальность; второй сохраняет generics, но требует статического вызова и отдельного API.

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

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

Команда разрабатывает систему обработчиков сообщений. Изначально обработчик описан трейтом с обобщённым методом, принимающим любой тип сообщения. Позже требуется собрать обработчики разных конкретных типов в один список и вызывать их единообразно через Vec<Box<dyn Handler>>.

Рассматривались два варианта. Сохранить обобщённый метод — значит оставить удобную статическую типизацию, но отказаться от трейтовых объектов. Заменить параметр типа на единый объект сообщения, например &dyn Message, позволяет использовать динамическую диспетчеризацию, но переносит проверку совместимости и часть стоимости вызова на время выполнения.

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

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

Можно ли вызвать обобщённый метод такого трейта через конкретный тип, если через dyn Trait он недоступен?

Да. Проблема относится к динамической диспетчеризации, а не к самому существованию реализации. Для конкретного типа компилятор знает Self и фактический параметр T, поэтому может мономорфизировать метод. Ограничение Self: Sized как раз обычно используется, чтобы сохранить такой статический вызов и одновременно не включать метод в интерфейс трейтового объекта.
Почему ограничение where Self: Sized не просто скрывает ошибку, а делает трейт объектно-совместимым?

Методы с таким ограничением не обязаны поддерживаться значением dyn Trait, поскольку dyn Trait не удовлетворяет требованию известного размера Self. Компилятор исключает этот метод из набора операций, разрешённых через трейтовый объект, и проверяет оставшиеся методы отдельно. Цена решения — невозможность вызвать ограниченный метод через &dyn Trait или Box<dyn Trait>.
Поможет ли замена параметра метода на ассоциированный тип сделать его вызов через трейтовый объект?

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