Ответ.

История вопроса

Одной из самых мощных возможностей Rust является паттерн-матчинг, реализованный через команду match. С выходом Rust 1.26 появился термин "match ergonomics" — новая логика распаковки и автоматического разыменования ссылочных значений внутри матч-выражений, призванная уменьшить количество явных ref и * в паттернах.

Проблема

До появления match ergonomics при использовании enum, оборачивающих значение в ссылку (например, Option<&T>), нужно было явно указывать разыменование паттерна:

let opt: Option<&i32> = Some(&10);
match opt {
    Some(&val) => { /* ... */ },
    None => {},
}

Что снижало читаемость и повышало вероятность ошибиться с уровнями разыменования в сложных структурах.

Решение

С введением match ergonomics Rust автоматически разыменовывает ссылки в паттернах, позволяя писать более простой и естественный код:

let opt: Option<&i32> = Some(&10);
match opt {
    Some(val) => println!("{}", val),
    None => (),
}

Компилятор "понимает", что нужно разыменовать &i32 до i32 для удобства программиста. Эта функция значительно облегчает работу с типами Option, Result и их комбинациями с ссылками.

Ключевые особенности:

Автоматическое разыменование в матч-паттернах (match ergonomics)
Снижение количества явных * и ref в паттернах
Повышение читаемости и краткости кода

Вопросы с подвохом.

В чём разница между использованием ref в паттерне и ссылкой на значение (например, ref val vs &val)?

ref создаёт ссылку на значение, находящееся на стеке, в то время как &val сопоставляется с уже существующей ссылкой. Это важно, например, если вам нужна дополнительная ссылка для работы с мутабельностью.

Пример:

let x = 5;
match x {
    ref r => println!("ref: {}", r), // r: &i32
}

Что произойдёт, если при pattern matching в Option<&T> использовать мутабельную ссылку?

Автоматическое разыменование работает и с мутабельными ссылками. Если у вас Option<&mut T>, то вы можете получить мутабельную переменную напрямую через match.

Пример:

let mut x = 5;
let opt = Some(&mut x);
match opt {
    Some(val) => *val += 1,
    None => {}
}

Может ли match ergonomics привести к неочевидным заимствованиям или ошибкам владения?

Может, если не осознавать, что внутри матча создаётся временное заимствование (borrow), которое действует на всю ветку матчинга и может блокировать другие операции с этим значением.

Типовые ошибки и анти-паттерны

Использовать избыточные * и ref, игнорируя match ergonomics, что снижает краткость и разборчивость кода
Ожидание автоматического клонирования, когда Rust только разыменовывает ссылку, но не создаёт новый объект

Пример из жизни

Негативный кейс

Новичок продолжает использовать старый стиль Some(&val) или Some(ref val), получая ошибку или непредсказуемое поведение при обновлении Rust до новой версии

Плюсы: Код работает на ранних версиях Rust и понятен тем, кто учился до появления match ergonomics

Минусы: Низкая выразительность, риск появления ошибок после обновлений компилятора

Позитивный кейс

Программист использует современные match ergonomics, питание кода компактное и эффективно использует автоматическое разыменование

Плюсы: Лаконичность, понятно читается, меньше риск ошибиться с уровнями ссылок

Минусы: Для старых версий Rust такой код не подойдёт и может вызвать непонимание у тех, кто мало работал с современной идиомой

Что такое 'match ergonomics' в Rust и как автоматическое разыменование влияет на работу с Option и Result?