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

Код не скомпилируется: trait object может иметь только один основной нетривиальный трейт, поэтому dyn Readable + Writable недопустим. Нужно объявить составной трейт, унаследованный от обоих, и использовать dyn ReadWrite.

trait Readable {
    fn read(&self) -> String;
}

trait Writable {
    fn write(&mut self, data: &str);
}

trait ReadWrite: Readable + Writable {}

fn process(value: &mut dyn ReadWrite) {
    value.write("data");
    println!("{}", value.read());
}

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

Трейты позволяют описывать поведение независимо от конкретного типа, а trait objects — выбирать реализацию динамически во время выполнения. Для вызова методов через dyn Trait компилятор использует таблицу виртуальных методов, связанную с одним основным трейтом.

Составной трейт решает задачу описания единого интерфейса, включающего несколько наборов методов. Это делает границу API именованной и позволяет явно выразить, какие реализации считаются совместимыми с этим интерфейсом.

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

Запись dyn Readable + Writable выглядит естественно, но Readable и Writable оба являются нетривиальными трейтами с методами. Rust не трактует такую запись как автоматическое создание нового составного интерфейса.

Если попытаться обойти ограничение отдельными аргументами, например передать &mut dyn Readable и &mut dyn Writable, возникнут дополнительные проблемы: это будут два независимых trait object, и из типов аргументов не следует, что они указывают на один и тот же объект.

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

В trait object разрешён один основной трейт. Дополнительными ограничениями могут быть, например, auto-трейты Send и Sync, а также lifetime-bound. Но два обычных поведенческих трейта нельзя просто объединить оператором + в типе объекта.

Составной трейт объявляется через supertrait-bound:

trait ReadWrite: Readable + Writable {}

Тип, реализующий ReadWrite, обязан реализовать оба родительских трейта. После этого dyn ReadWrite предоставляет методы обоих трейтов, если они совместимы с использованием через trait object.

Обычно для конкретного типа достаточно пустой реализации составного трейта:

struct File;

impl Readable for File {
    fn read(&self) -> String { "content".into() }
}

impl Writable for File {
    fn write(&mut self, _data: &str) {}
}

impl ReadWrite for File {}

Это не создаёт новую реализацию методов: ReadWrite лишь фиксирует обязательный набор базовых трейтов. Вызов process(&mut file) использует динамическую диспетчеризацию через dyn ReadWrite; конкретный тип File в сигнатуре функции не раскрывается.

Альтернатива — сделать функцию обобщённой:

fn process_generic<T: Readable + Writable>(value: &mut T) {
    value.write("data");
    println!("{}", value.read());
}

Здесь используется статическая диспетчеризация и сохраняется конкретный тип T, но функция становится generic и обычно специализируется для каждого применённого типа. dyn ReadWrite удобнее, когда набор реализаций должен храниться или передаваться единообразно во время выполнения.

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

Плагин должен уметь читать и изменять конфигурацию, а контейнер приложения хранит разные плагины в одном списке. Вариант с Vec<Box<dyn Readable>> теряет доступ к write, а вариант с двумя отдельными trait object не гарантирует, что чтение и запись выполняются над одним экземпляром.

Вариант с generic-параметром Vec<Box<T>> не подходит для разных конкретных типов: один Vec имеет один тип элемента. Поэтому выбирается trait ReadWrite и контейнер Vec<Box<dyn ReadWrite>>.

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

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

Вопрос: достаточно ли написать trait ReadWrite: Readable + Writable {} без impl ReadWrite for File?

Ответ: нет. Наследование трейтов задаёт требования к реализации, но не создаёт реализацию ReadWrite автоматически для каждого типа, реализующего Readable и Writable. Для конкретного типа нужна отдельная реализация, например impl ReadWrite for File {}.
Вопрос: можно ли заменить составной трейт generic-bound T: Readable + Writable?

Ответ: да, если функции не требуется стирать конкретный тип. Такой bound гарантирует наличие обоих трейтов и использует статическую диспетчеризацию. Но он не позволяет напрямую хранить в одной коллекции значения разных конкретных типов без дополнительного trait object или другого общего представления.
Вопрос: что произойдёт, если один из методов родительского трейта использует Self в несовместимой с trait object форме?

Ответ: составной трейт тоже нельзя будет использовать как dyn ReadWrite. Например, метод, возвращающий Self, обычно требует статического знания конкретного типа и нарушает dyn-совместимость. Составной трейт не устраняет ограничения родительских трейтов, а только объединяет их требования.