Traits и generics

В API объект должен поддерживать оба независимых трейта. Разберите, допустим ли такой trait object и как выразить эту границу корректно:

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

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

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

Как правило вывода времени жизни различает Box<dyn Trait> и &dyn Trait без явного lifetime-bound?

При проектировании структуры нужно скрыть конкретный тип поля за трейт-границей. Почему impl Trait нельзя использовать для этого напрямую?

Как отсутствие параметра self у ассоциированной функции влияет на её вызов через dyn Trait?

При создании trait object для трейта с параметром типа как Rust определяет, какой тип параметра закреплён за объектом, и почему один такой объект не может обслуживать разные типы параметра?

Как приём self по значению влияет на совместимость метода с dyn Trait и возможность его вызова?

Две разные функции возвращают impl Trait с одинаковыми bounds. Совместимы ли их скрытые типы?

Ваша обёртка должна реализовывать трейт только при выполнении bound внутренним типом. Как Rust определяет доступность такой реализации при вызове метода?

Объясните механизм: почему точечный вызов метода может найти реализацию трейта для ссылки на значение, хотя исходное выражение имеет тип самого значения?

Почему обобщённую функцию нельзя сохранить как значение без выбора конкретных типов параметров?

Почему метод трейта с возвращаемым impl Trait нельзя вызвать через dyn Trait?

Как Rust трактует impl Add for T, если у трейта Add параметр Rhs имеет значение по умолчанию?

Как ограничение Self: Sized на самом трейте влияет на возможность использовать его как dyn Trait?

В библиотечном трейте параметр типа имеет значение по умолчанию: что именно происходит при использовании трейта без явного параметра?

В практическом API объект хранится как Box<dyn Trait>, но реализация трейта содержит ссылку на данные вызывающего кода. Какой lifetime-bound потребуется и почему?

Практическая ситуация: API должен принимать любой тип с трейтом Readable, кроме типов с признаком Encrypted. Почему такой bound нельзя выразить напрямую в Rust?

В библиотечном API проверьте, достаточно ли bound трейта для вызова clone у ассоциированного типа без повторения ограничения:

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

fn duplicate<C: Container>(container: C) -> (C::Item, C::Item) {
    let value = container.item();
    (value.clone(), value)
}

Скомпилируется ли функция duplicate?

Как компилятор трактует параметр типа в реализации трейта, который упомянут только в where-bound, но не связан с Self?

Проверьте, скомпилируется ли вызов обобщённой функции для Box<dyn Describe>, и объясните результат.

trait Describe {
    fn describe(&self) -> &'static str;
}

struct Item;
impl Describe for Item {
    fn describe(&self) -> &'static str { "item" }
}

fn inspect<T: Describe>(value: T) {
    println!("{}", value.describe());
}

fn main() {
    let boxed: Box<dyn Describe> = Box::new(Item);
    inspect(boxed);
}

Какие свойства скрытого типа доступны вызывающему функции с возвращаемым impl Trait, если они не указаны в её bounds?