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

Ассоциированный тип задаётся реализацией трейта и един для конкретной пары «тип — трейт», поэтому один тип не может иметь несколько реализаций такого трейта с разными ассоциированными типами. Параметр типа входит в идентичность реализации, поэтому один тип может реализовать обобщённый трейт несколько раз для разных аргументов типа.

Это влияет и на использование API: ассоциированный тип выбирает реализация, а параметр типа обычно выбирается вызывающим кодом. Для динамической диспетчеризации ассоциированный тип должен быть заранее зафиксирован.

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

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

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

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

Предположим, есть тип преобразователя, который умеет обрабатывать разные входные типы. Если входной тип является параметром трейта, можно отдельно реализовать трейт для строк, байтов или другого входа.

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

Неверный выбор создаёт практические последствия: параметр типа может сделать API гибче, но усложнить вывод типов и вызовы; ассоциированный тип делает контракт однозначнее, но запрещает несколько вариантов одной связи.

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

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

trait Преобразователь<T> {
    type Выход;
    fn преобразовать(&self, значение: T) -> Self::Выход;
}

struct Парсер;

impl Преобразователь<String> for Парсер {
    type Выход = u32;
    fn преобразовать(&self, _: String) -> u32 { unimplemented!() }
}

impl Преобразователь<Vec<u8>> for Парсер {
    type Выход = u32;
    fn преобразовать(&self, _: Vec<u8>) -> u32 { unimplemented!() }
}

Здесь Парсер реализует Преобразователь<String> и Преобразователь<Vec<u8>>. Выбор реализации определяется аргументом типа трейта, поэтому эти реализации не конфликтуют.

У ассоциированного типа реализация выглядит концептуально иначе: Элемент выбирается внутри impl. Для одной пары «конкретный тип — конкретный трейт» может существовать только одна согласованная реализация из-за правил согласованности и когерентности Rust.

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

Это также влияет на диспетчеризацию. Вызов через generic-параметр обычно получает статическую диспетчеризацию и может быть мономорфизирован для каждого конкретного типа. Вызов через dyn Trait использует динамическую диспетчеризацию; ассоциированный тип при этом должен быть зафиксирован, например в форме dyn Iterator<Item = u8>, иначе интерфейс остаётся неоднозначным.

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

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

Команда проектировала API для обработчиков входных данных. Один объект-обработчик должен был принимать как текст, так и массив байтов, возвращая нормализованный результат.

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

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

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

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

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

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

В статически типизированном обобщённом контексте компилятор обычно может вывести его из конкретной реализации. Но при динамической диспетчеризации конкретное значение ассоциированного типа должно быть указано в ограничении объектного типа, например dyn Iterator<Item = u8>; иначе вызов не имеет однозначного результата.
Как правила когерентности ограничивают несколько реализаций обобщённого трейта?

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