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

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

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

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

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

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

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

Если функция-посредник объявлена как принимающая произвольный U, компилятор не может предположить, что U: Display. Даже если фактический тип в конкретном вызове поддерживает Display, внутри обобщённой функции разрешены только гарантии, явно выраженные её bounds.

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

Условная реализация формирует логическое правило: Wrapper<T>: Render только если T: Display. При проверке вызова render_value компилятор должен одновременно установить два факта: аргумент реализует Render, а для этого выполнено условие T: Display.

use std::fmt::Display;

trait Render {
    fn render(&self) -> String;
}

struct Wrapper<T>(T);

impl<T: Display> Render for Wrapper<T> {
    fn render(&self) -> String { self.0.to_string() }
}

fn render_value<T: Render>(value: T) -> String {
    value.render()
}

fn use_wrapper<T: Display>(value: Wrapper<T>) -> String {
    render_value(value)
}

В use_wrapper bound T: Display необходим: он позволяет вывести, что Wrapper<T>: Render, и затем удовлетворить bound функции render_value. Если убрать T: Display, вызов станет некорректным, потому что для произвольного T реализация Render не доказана.

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

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

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

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

В библиотеке есть универсальный контейнер Wrapper<T> и функция форматирования, принимающая T: Render. Разработчик написал адаптер для произвольного T, но не добавил ему bound Display; ошибка проявилась при компиляции библиотеки, хотя все реальные типы приложения поддерживали Display.

Рассматривались два варианта. Можно было реализовать Render для Wrapper<T> безусловно, но тогда пришлось бы требовать другой способ форматирования или хранить дополнительные данные; это усложняло модель и могло привести к неуместной реализации. Можно было добавить T: Display в адаптер — это ограничивало применимость, зато точно отражало необходимое условие.

Выбрали второй вариант: bound добавили на функцию-посредник и оставили условную реализацию. В результате ошибка стала локальной и понятной, а типы без Display по-прежнему могли использовать Wrapper<T> в других сценариях, не требующих Render.

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

1. Достаточно ли добавить bound только в месте конечного вызова?

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

Например, внешний вызов может передавать Wrapper<String>, но функция, объявленная для любого T без T: Display, обязана быть корректной для всех допустимых T, а не только для String.

2. Может ли bound появиться автоматически из вызова другой generic-функции?

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

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

3. Что изменится, если условная реализация конфликтует с безусловной?

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

Поэтому нельзя безопасно объявить безусловную реализацию Render для Wrapper<T> и одновременно условную реализацию Render для Wrapper<T> при T: Display. Это ограничение поддерживает однозначность разрешения traits и предотвращает нарушение согласованности программы.