В коде обобщённая функция печатает ассоциированный тип. Какое ограничение нужно добавить, чтобы вызов print...

use std::fmt::Display;

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

fn show<S: Source>(source: S) {
    println!("{}", source.item());
}

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

Нужно ограничить не сам тип S, а его ассоциированный тип: S::Item: Display. Ограничение S: Display было бы недостаточным, потому что форматируется результат source.item(), то есть значение типа S::Item.

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

Обобщения позволяют писать функцию один раз для множества типов, но компилятор должен знать, какие операции допустимы для каждого параметра типа. В Rust эти гарантии выражаются через границы типов — trait bounds.

Ассоциированные типы позволяют трейту объявить связанный с реализацией тип без добавления отдельного параметра типа к каждому использованию трейта. Поэтому при работе с S::Item ограничение нужно накладывать именно на проекцию ассоциированного типа.

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

В теле show компилятор видит только условие S: Source. Из этого следует, что у S существует метод item и известен некоторый тип S::Item, но не следует, что этот тип реализует Display.

Если не добавить нужный bound, обобщённая функция не скомпилируется. Проверка выполняется для всех возможных типов S, соответствующих объявленным ограничениям, а не только для тех реализаций Source, которые уже находятся в текущем модуле.

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

Ограничение записывается так:

use std::fmt::Display;

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

fn show<S>(source: S)
where
    S: Source,
    S::Item: Display,
{
    println!("{}", source.item());
}

Запись S::Item: Display означает: для любого конкретного S, переданного в show, его ассоциированный тип Item должен реализовывать Display. Это проверяется после разрешения ассоциированного типа конкретной реализацией трейта.

Например, если S::Item равен u32, ограничение выполнено, потому что u32 реализует Display. Если реализация указывает Item = SomeType, не реализующий Display, такой тип нельзя передать в show.

Важно отличать это от ограничения S: Display. Последнее требовало бы форматируемости самого источника S, хотя функция форматирует значение, возвращённое методом item. Bound на ассоциированный тип точнее выражает контракт API и не требует лишних возможностей от S.

Ограничение можно объявить и в самом трейте: type Item: Display. Тогда каждая реализация Source обязана использовать тип Item, реализующий Display. Это усиливает общий контракт трейта и может быть неудобно, если другим пользователям трейта нужна поддержка типов без Display.

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

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

Вариант с type Item: Display в объявлении Source прост для пользователей функции вывода, но навязывает Display всем реализациям, включая те, которым форматирование не нужно. Это уменьшает повторное написание bounds, но делает трейт менее универсальным.

Вариант с S::Item: Display в конкретной функции оставляет Source общим, а требование форматируемости появляется только там, где действительно вызывается форматирование. Для библиотечного API обычно выбирают этот вариант: он сохраняет больше допустимых реализаций и точнее описывает зависимости операции.

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

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

1. Можно ли записать bound на ассоциированный тип рядом с параметром типа?

Да. Эквивалентная форма выглядит так:

fn show<S: Source>(source: S)
where
    S::Item: Display,
{
    println!("{}", source.item());
}

Смешение bounds в угловых скобках и в where-блоке влияет в основном на читаемость. Для проекций вроде S::Item where обычно удобнее, потому что сложные ограничения остаются отделёнными от списка параметров.

2. Почему компилятор не выводит это ограничение из конкретных реализаций Source?

Потому что функция объявлена для любого S: Source. В момент проверки тела функции компилятор не может подменить обобщённый контракт набором реализаций, известных сейчас: в другом модуле может существовать допустимая реализация Source с типом Item, не реализующим Display.

Даже если единственная текущая реализация использует u32, это не становится частью объявления show. Явный bound делает требование частью проверяемого контракта и позволяет компилятору гарантировать корректность для всех допустимых подстановок.

3. Когда лучше перенести ограничение Display в сам трейт?

Это оправдано, если Display — обязательное свойство каждого элемента любого Source, а не требование отдельной операции. Тогда можно объявить type Item: Display, и все методы и функции, работающие с Source, получают эту гарантию автоматически.

Если же часть источников должна возвращать типы без Display, bound следует оставить на конкретной функции. Такой дизайн слабее связывает компоненты, допускает больше реализаций и позволяет добавлять другие операции с собственными требованиями, например S::Item: Serialize или S::Item: Debug.