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

Код не скомпилируется: для типа Job доступны две реализации метода run, поэтому обычный вызов Job.run() неоднозначен. Нужно явно указать трейт через полностью квалифицированный синтаксис: Fast::run(&Job) или Safe::run(&Job).

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

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

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

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

В примере Job реализует два метода с одинаковой сигнатурой run. При записи Job.run() компилятор видит несколько подходящих кандидатов, но не знает, требуется ли быстрый или безопасный вариант.

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

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

Для выбора конкретной реализации используется синтаксис Trait::method(&value):

trait Fast {
    fn run(&self) -> &'static str;
}

trait Safe {
    fn run(&self) -> &'static str;
}

struct Job;

impl Fast for Job {
    fn run(&self) -> &'static str { "fast" }
}

impl Safe for Job {
    fn run(&self) -> &'static str { "safe" }
}

fn main() {
    println!("{}", Fast::run(&Job));
    println!("{}", Safe::run(&Job));
}

Fast::run(&Job) означает вызов метода run, принадлежащего именно трейту Fast, с передачей ссылки на Job как параметра self. Этот синтаксис называют UFCS или полностью квалифицированным вызовом.

Если значение уже сохранено в переменной, используется тот же подход: Fast::run(&job). Вызов job.run() допустим только тогда, когда среди доступных методов нет неоднозначности или типовая информация и контекст однозначно выбирают одного кандидата.

Ситуация отличается от конфликта с одноимённым методом, объявленным непосредственно в типе. Inherent method обычно имеет приоритет над методами трейтов при вызове через точку. Однако если требуется гарантированно вызвать реализацию трейта, UFCS остаётся явным и надёжным способом.

Для generic-кода неоднозначность также устраняется явным указанием трейта:

fn execute<T: Fast + Safe>(value: &T) -> &'static str {
    Fast::run(value)
}

Здесь bounds разрешают передать только тип, реализующий оба трейта, а Fast::run фиксирует выбранное поведение. Без квалификации вызов value.run() снова был бы неоднозначным.

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

Представим тип Request, который реализует трейты Serialize и Debug, причём оба предоставляют метод format. В небольшом месте можно написать UFCS непосредственно у вызова. Это минимально изменяет API и не требует добавления новых методов.

Другой вариант — переименовать методы, например в serialize_format и debug_format. Такой API понятнее при частых вызовах, но изменение имён может быть невозможно для внешних трейтов и ухудшить совместимость с уже существующим интерфейсом.

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

Для разового или локального выбора оптимален UFCS: он сохраняет независимые трейты, не меняет публичный API и явно фиксирует нужную реализацию. В результате код компилируется, а добавление новых трейтов не меняет смысл уже квалифицированных вызовов.

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

1. Всегда ли вызов через точку неоднозначен, если два трейта содержат одинаковый метод?

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

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

2. Меняет ли UFCS способ динамической диспетчеризации?

Сам по себе UFCS только уточняет, какой метод вызывается; он не превращает статическую диспетчеризацию в динамическую и наоборот. Для конкретного типа вроде Job компилятор обычно знает реализацию на этапе компиляции.

Если вызов выполняется через dyn Trait, например &dyn Fast, он остаётся вызовом метода выбранного trait object и использует динамическую диспетчеризацию. При этом вызвать через &dyn Fast метод из Safe нельзя: объект предоставляет только интерфейс указанного трейта.

3. Можно ли разрешить конфликт, импортировав один из трейтов?

Импорт не делает выбор реализации надёжным способом. use влияет на доступность имён, но если оба трейта уже участвуют в разрешении метода, конфликт следует устранить явным вызовом Fast::run(&value) или Safe::run(&value).

Иногда можно ограничить область видимости трейта, но это хрупкое решение: изменение импортов способно снова изменить набор кандидатов. Для выражения намерения и стабильного кода предпочтителен UFCS.