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

Реализация будет отклонена: Rust не позволяет сделать требования метода в impl строже, чем требования метода в объявлении трейта. Реализация должна быть пригодна для каждого типа, для которого выбран данный impl, иначе она нарушает контракт трейта.

Дополнительное условие допустимо не на самом методе, а на всей реализации трейта. Тогда реализация существует только для типов, удовлетворяющих этому условию.

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

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

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

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

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

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

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

В impl Rust проверяет не только наличие метода, но и совместимость его сигнатуры с объявлением трейта. Bound метода в реализации не может быть сильнее bound исходного метода; ошибка обычно описывается как наличие более строгих требований в реализации.

use std::fmt::Display;

trait Convert {
    fn convert(&self) -> String;
}

impl<T> Convert for T {
    fn convert(&self) -> String
    where
        T: Display,
    {
        self.to_string()
    }
}

Такой вариант некорректен: объявление Convert::convert не требует Display, поэтому реализация не может добавить это требование только к методу.

Правильный вариант ограничивает сам impl:

use std::fmt::Display;

trait Convert {
    fn convert(&self) -> String;
}

impl<T: Display> Convert for T {
    fn convert(&self) -> String {
        self.to_string()
    }
}

Теперь Convert реализуется только для типов T, реализующих Display. Внутри выбранной реализации метод уже не нуждается в дополнительном локальном bound: он гарантирован bound всего impl.

Важно различать два уровня ограничений. Bound на impl определяет множество типов, для которых существует реализация; bound на методе определяет условия вызова метода. Для соответствия трейту эти условия не могут быть строже условий метода в самом трейте.

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

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

В библиотеке форматирования разработчик создаёт трейт Encode, общий для всех поддерживаемых типов. Для одного blanket-impl он использует Display, но добавляет это ограничение только к методу реализации.

Возможны два решения. Первое — оставить bound на методе: оно кажется локальным и компактным, но нарушает контракт трейта и не компилируется. Второе — перенести Display на impl: реализация становится условной, зато её метод корректен для каждого типа из заявленного множества.

Выбирается второй вариант. Он явно отражает API-условие: тип считается Encode только тогда, когда его можно отобразить через Display. Это сохраняет корректность обобщённого кода и делает выбор реализации прозрачным для компилятора.

Если же Encode действительно должен поддерживать типы без Display, следует изменить сам контракт трейта — например, добавить отдельный метод или передавать кодировщик как параметр. Нельзя скрывать обязательное условие внутри одной реализации метода.

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

Можно ли ослабить bound метода в реализации по сравнению с трейтом?

Да, реализация не обязана повторять каждое ограничение буквально, если её сигнатура остаётся совместимой с контрактом. Но ослабление обычно ничего не меняет для вызывающего кода: он всё равно видит требования, объявленные трейтом. Запрещено именно усиление требований, потому что оно сокращает множество допустимых вызовов.
Чем отличается bound на impl от bound на обобщённой функции, вызывающей метод?

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

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