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

Нет. Ограничение T: Trait гарантирует реализацию трейта для самого типа T, но не для ссылочного типа &T: в Rust T и &T — разные типы. Реализация для &T должна существовать отдельно, например через явную или blanket-реализацию.

При этом вызов метода может работать благодаря автоматическому разыменованию: компилятор способен перейти от &T к T при поиске метода. Это не означает, что &T удовлетворяет bound Trait в обобщённом контексте.

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

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

Автоматическое разыменование существует как удобство именно для синтаксиса вызова методов. Оно не превращает один тип в другой и не расширяет логические гарантии обобщённого параметра.

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

Рассмотрим функцию, которая принимает произвольный тип R, но требует от него реализацию Tag. Если другая функция имеет только bound T: Tag и передаёт ссылку &T первой функции, компилятор должен проверить bound для конкретного типа &T, а не для исходного T.

Если такой реализации нет, вызов отклоняется. Попытка полагаться на то, что ссылка автоматически будет рассматриваться как исходное значение, приводит к ошибкам в generic-коде, особенно при передаче значений в функции, структурах или других параметрах типов.

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

В этом примере String реализует Tag, но &String — нет:

trait Tag {}

impl Tag for String {}

fn accept<R: Tag>(_: R) {}

fn demo<T: Tag>(value: &T) {
    accept(value); // ошибка: для &T не доказан bound Tag
}

fn main() {}

Внутри demo компилятор знает только, что T: Tag. При вызове accept(value) параметр R выводится как &T, поэтому требуется доказать &T: Tag. Из T: Tag это автоматически не следует.

Это отличается от вызова метода. Если у трейта есть метод с подходящим receiver, выражение вроде value.some_method() может использовать autoderef и найти метод реализации для T. Проверяется доступность метода через цепочку разыменований, а не наличие реализации трейта непосредственно для типа &T.

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

изменить API так, чтобы он принимал ссылку отдельно: например, fn accept<T: Tag + ?Sized>(_: &T);
добавить bound for<'a> &'a T: Tag, если именно ссылка должна реализовывать трейт;
определить blanket-реализацию Tag для ссылок, если такая семантика корректна для всего API.

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

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

В библиотеке есть generic-функция, принимающая значение, реализующее трейт сериализации. Клиент хочет передавать туда &T, где T сериализуем. Прямое добавление bound T: Serialize не решает проблему: вызываемый API получает тип ссылки и требует &T: Serialize.

Вариант с blanket-реализацией для &T удобен: все сериализуемые типы автоматически становятся сериализуемыми по ссылке. Минус — библиотека закрепляет это поведение для всех будущих типов и может столкнуться с пересечением реализаций.

Более безопасный вариант — изменить сигнатуру функции на приём ссылки и оставить bound на T. Тогда функция явно работает с заимствованными данными, не требуя отдельного трейта для ссылочного типа. Для библиотечного API обычно выбран именно этот вариант: он точнее отражает модель владения и не расширяет глобальное множество реализаций.

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

Вопрос: Может ли Box<T> автоматически удовлетворять bound T: Trait, если T реализует этот трейт?

Ответ: Нет, Box<T> также является отдельным типом. Вызов метода через Box<T> может работать благодаря автоматическому разыменованию, но передача Box<T> в параметр с bound Trait требует реализации Trait для Box<T>. Её можно предоставить явно или blanket-реализацией, если это разрешено правилами согласованности.
Вопрос: Почему вызов метода через &T иногда успешен, хотя &T: Trait не доказан?

Ответ: Синтаксис вызова метода использует специальные правила поиска: компилятор может автоматически разыменовать receiver и подобрать метод, реализованный для T. Это удобство языка для вызовов методов, а не общее преобразование типа &T в T. Вызов обычной generic-функции с параметром R: Trait таких правил для доказательства R: Trait не получает.
Вопрос: Что меняется после blanket-реализации трейта для всех ссылок на типы, реализующие исходный трейт?

Ответ: Тогда bound для &T действительно становится выводимым из bound для T, потому что появляется явное правило реализации. Однако такая реализация может пересечься с другой реализацией для конкретного ссылочного типа или ограничить возможность добавить её в будущем. Кроме того, нужно определить корректную семантику receiver: не каждый трейт, реализуемый для значения, имеет смысл автоматически реализовывать для ссылки.