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

Для trait object нужно явно указать значение каждого используемого ассоциированного типа. Поэтому объект должен иметь вид dyn Trait<АссоциированныйТип = КонкретныйТип>: без этого Rust не знает точный тип результатов методов трейта и не может сформировать однозначный интерфейс объекта.

Это ограничение фиксирует ассоциированный тип для конкретного trait object. Объекты одного и того же трейта с разными значениями ассоциированного типа считаются разными типами объектов.

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

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

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

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

Рассмотрим трейт с методом, возвращающим ассоциированный тип. Если разрешить неопределённый dyn Trait, один объект мог бы потенциально возвращать разные несовместимые типы в зависимости от конкретной реализации.

Это нарушило бы типобезопасность вызывающего кода: он не смог бы понять, какой тип имеет результат метода. Поэтому Rust запрещает использовать trait object с неуказанным ассоциированным типом.

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

Ассоциированный тип задаётся в самом типе trait object через equality-bound. Например:

trait Source {
    type Item;
    fn get(&self) -> Self::Item;
}

struct Counter;

impl Source for Counter {
    type Item = u32;
    fn get(&self) -> u32 { 42 }
}

fn read(source: &dyn Source<Item = u32>) -> u32 {
    source.get()
}

В read гарантировано, что get возвращает u32, поэтому результат можно использовать как значение этого типа. Trait object хранит указатель на данные и указатель на vtable; vtable соответствует реализации, совместимой с указанным ассоциированным типом.

Запись dyn Source без Item = ... недостаточна. В отличие от generic-параметра, который может быть отдельно выведен или подставлен для конкретного вызова, trait object должен иметь один полностью определённый тип интерфейса во время компиляции.

Это не означает, что сам трейт нельзя реализовать с разными ассоциированными типами. Можно иметь разные реализации для разных типов-носителей, но каждый trait object фиксирует только один вариант. Объект dyn Source<Item = u32> нельзя передать туда, где ожидается dyn Source<Item = String>.

Если требуется работать с реализациями, возвращающими разные типы, есть несколько вариантов:

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

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

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

В библиотеке есть несколько источников токенов. Каждый источник реализует трейт Source, но один возвращает токены выражений, а другой — токены ошибок. Разработчик пытается хранить их в одном контейнере как объекты одного трейта.

Вариант с dyn Source не подходит: ассоциированный тип не определён. Вариант с dyn Source<Item = Token> работает только для источников, возвращающих именно Token; источник с другим типом результата туда добавить нельзя.

Если набор вариантов известен заранее, разумное решение — общее перечисление токенов и trait object с фиксированным ассоциированным типом. Если тип результата должен оставаться параметром конкретного вызова, лучше использовать generic-контейнер. Если набор типов открыт и определяется во время выполнения, можно применить дополнительное стирание типа, но это усложняет извлечение значения и обычно требует проверок или преобразований.

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

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

Можно ли указать ассоциированный тип только в месте вызова метода?

Нет. Для trait object ассоциированный тип является частью самого типа объекта, а не отдельной настройкой конкретного вызова. Если объект объявлен без необходимого equality-bound, Rust отклонит его уже при формировании типа или использовании трейта как объекта.

Разрешает ли фиксация ассоциированного типа хранить разные реализации трейта в одном контейнере?

Да, если все реализации имеют одинаковое значение ассоциированного типа. Например, разные структуры могут реализовать Source с Item = u32, и их можно представить как dyn Source<Item = u32>. Различия между структурами скрываются за vtable, но различия в ассоциированном типе скрыть таким способом нельзя.

Чем это отличается от параметра типа у трейта?

Параметр типа обычно делает разные специализации частью разных применений самого трейта, а ассоциированный тип задаёт один результат для конкретной реализации. Для trait object в обоих случаях требуется получить однозначный объектный интерфейс, но ассоциированный тип фиксируется equality-bound непосредственно в записи объекта. Если нужны реализации одного типа для нескольких вариантов результата, ассоциированный тип этого не выражает; тогда может потребоваться другой дизайн трейта или отдельный параметр типа.