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

Такая реализация отклоняется: параметр типа считается несвязанным. Параметр T должен участвовать в типе Self, в аргументах реализуемого трейта или быть однозначно связанным через допустимое ограничение; одного условия вроде T: SomeTrait недостаточно.

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

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

Обобщённые реализации позволяют описать целое семейство реализаций одним блоком: например, реализовать трейт для Wrapper<T> при условии, что T поддерживает нужную операцию. Такой подход избавляет от дублирования и сохраняет статическую проверку типов.

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

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

Рассмотрим мысленную реализацию трейта Describe для типа Report, где T встречается только в bound T: ToString. Сам Report не зависит от T, и Describe тоже не принимает T как параметр.

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

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

Параметр становится связанным, если он появляется в реализуемом типе или в самом пути трейта. Например, в Report<T> компилятор видит связь между конкретным экземпляром Report и конкретным T:

trait Describe {
    fn describe(&self) -> String;
}

struct Report<T>(T);

impl<T: ToString> Describe for Report<T> {
    fn describe(&self) -> String {
        self.0.to_string()
    }
}

Здесь Report<u32> и Report<String> — разные типы, поэтому выбор реализации однозначен. Bound T: ToString дополнительно гарантирует, что тело реализации может вызвать to_string.

Если тип Self менять нельзя, зависимость часто переносят в сам трейт: делают его параметризованным, например Formatter<T>. Тогда T становится частью реализуемого trait path, а Formatter<u32> и Formatter<String> — различными специализациями.

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

PhantomData<T> может формально связать T с Self, но это не просто косметический обход. Он способен влиять на variance, автоматические трейты Send и Sync, а также на анализ владения и времени жизни. Поэтому его применяют только когда такая логическая связь действительно соответствует модели типа.

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

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

Возможны три варианта:

связать T с Self, например использовать Report<T>; это обеспечивает однозначность и статическую диспетчеризацию, но меняет представление типа;
сделать T параметром трейта; это сохраняет Report неизменным, но усложняет имя трейта и все места его использования;
сделать T параметром метода; это удобно для разных входных значений, но накладывает требования на каждую реализацию и ограничивает динамическое использование метода.

Если формат является свойством самого отчёта, выбирают Report<T>. Это наиболее точное решение: тип данных явно отражает зависимость, а компилятор может мономорфизировать реализацию без скрытого выбора параметра.

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

Разве bound не связывает T, если он сильно ограничивает множество типов?

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

Достаточно ли добавить PhantomData<T>, чтобы безопасно исправить ошибку?

Технически это может связать параметр с Self, если PhantomData<T> входит в структуру. Но такой маркер сообщает компилятору, что тип логически зависит от T, и это влияет не только на проверку реализации. Можно непреднамеренно изменить автоматические трейты, variance или правила обращения с временем жизни. Поэтому сначала нужно проверить модель владения; если связи в предметной области нет, лучше параметризовать трейт или метод.

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

Параметр трейта выбирается на уровне реализации: Trait<A> и Trait<B> являются разными trait path, а конкретная реализация однозначно определяется типом и этим параметром. Параметр метода выбирается при каждом вызове, поэтому один объект может принимать разные типы, но каждая реализация должна поддерживать весь допустимый набор T. Такая гибкость обычно несовместима с вызовом этого метода через trait object и чаще используется при статической диспетчеризации.