Программирование Rust

В коде поток получает собственное владение Rc<Mutex<i32>>, но компилятор всё равно отклоняет запуск. Объясните, какой механизм делает такую передачу недопустимой.

use std::{rc::Rc, sync::Mutex, thread};

fn main() {
    let counter = Rc::new(Mutex::new(0));
    let worker_counter = Rc::clone(&counter);

    thread::spawn(move || {
        *worker_counter.lock().unwrap() += 1;
    }).join().unwrap();
}

Разберите ошибку в пользовательском future: почему runtime не сможет гарантированно продолжить выполнение задачи после первой проверки?

После запуска потока компилятор отклоняет этот код. Какое ограничение времени жизни нарушено захваченным значением?

use std::thread;

fn main() {
    let message = String::from("готово");
    let handle = thread::spawn(|| {
        println!("{message}");
    });
    handle.join().unwrap();
}

В коде ниже компилятор отвергает создание Pin<&mut F>. Какое свойство async-future делает закрепление в памяти необходимым перед передачей future исполнителю?

use std::future::Future;
use std::pin::Pin;

async fn task() {
    let text = String::from("data");
    async {}.await;
    println!("{text}");
}

fn pollable<F: Future>(mut future: F) {
    let pinned = Pin::new(&mut future);
    let _ = pinned;
}

fn main() {
    pollable(task());
}

Что происходит с async-операцией в Rust, когда её future уничтожают до завершения?

Разберите последствия выполнения блокирующей синхронной операции внутри async-задачи однопоточного runtime Rust.

Представьте, что поток передаёт другому потоку общую ссылку на значение типа T. Какой маркер потокобезопасности обязан реализовывать T?

В практической ситуации производитель отправляет сообщения быстрее потребителя: как ограниченный async-канал применяет обратное давление?

Как async runtime приводит созданный future к выполнению?

Объясните механизм: почему async-задача с несинхронным состоянием между точками ожидания может быть отклонена многопоточным runtime?

В 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 определяет доступность такой реализации при вызове метода?

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

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