Ответ.

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

Pattern matching — один из важнейших языковых механизмов в Rust, пришедший из функциональных языков. Он позволяет декларативно, лаконично и безопасно разбирать сложные варианты значений, в том числе с помощью дополнительных условий (guard-выражений), что даёт гибкость и контроль над логикой.

Проблема

Без exhaustiveness checking (проверка исчерпывающего рассмотрения всех вариантов) часть сценариев мощности pattern matching может быть реализована с ошибками. Кроме того, без понимания порядка веток и guard-выражений можно ошибиться либо в логике, либо в производительности.

Решение

В Rust компилятор проверяет, что все варианты enum (или более простых pattern-структур) разобраны, либо есть ветка _. Ветка может быть дополнительно ограничена guard-выражением (if после pattern), и только при выполнении условия она "срабатывает". Оставшиеся варианты — не захватываются. Порядок веток важен: они проверяются сверху вниз.

Пример кода:

enum Message {
    Hello,
    Data(i32),
    Quit,
}

fn handle(msg: Message) -> &'static str {
    match msg {
        Data(n) if n > 10 => "Big Data",
        Data(_) => "Some Data",
        Hello => "Greet!",
        Quit => "Bye",
    }
}

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

• Safety за счёт exhaustiveness checking: компилятор не даст пропустить случаи (или заставит явно поставить '_').
• Возможность использовать guard для расширения условий обработки.
• Ветки проверяются по порядку сверху вниз, первый совпавший pattern+guard срабатывает.

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

Срабатывает ли ветка с guard, если pattern совпал, но условие не выполняется?

Нет, в таком случае проверка идёт к следующей подходящей ветке. Pattern + guard — это атомарный "фильтр"; только когда оба совпали, выполняется тело ветки.

Влияет ли порядок веток в match на производительность?

Да. Особенно при обилии похожих паттернов с guard: компилятор проверяет ветки сверху вниз, что влияет на скорость проверки в рантайме — встречаемые чаще значения стоит обрабатывать раньше.

Можно ли опустить exhaustiveness checking, поставив только ветку _?

Технически да — это допустимо, но теряется надёжность: если тип исключит (или добавит) new элементы, компилятор не предупредит о нерассмотренном случае. Лучше всегда явно обрабатывать важные, а "_" — только в крайнем случае.

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

• Использование guard без осознания, что паттерн якобы совпал, но условие не прошло: неучтённые случаи.
• Игнорирование порядка веток при неоднозначных паттернах, неверная логика.
• Всегда стоить разбирать enum exhaustively, не заливая всё в "_".

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

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

Код match для enum с guard-выражениями, где паттерн с guard идёт последним, но большинство значений проходит напрямую по ранней ветке _, и никогда не доходит до нужной обработке.

Плюсы:

• Быстрая реализация "затычки" в виде _.

Минусы:

• Логика не работает, нужные значения не ловятся, а код тяжело тестировать.

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

Сначала перечисляются наиболее частые и важные варианты (с guard), затем exhaustively покрываются остальные — без лишнего кода в "_".

Плюсы:

• Код легко читать и поддерживать, высокая надёжность.

Минусы:

• Требует вдумчивого проектирования структуры enum и порядка веток.