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

Если в перечисление добавить новый вариант, существующий match перестанет компилироваться, когда его шаблоны больше не покрывают все возможные варианты. Это заставляет явно обработать новый случай либо сознательно использовать общий шаблон, например _.

Такое поведение делает изменение модели данных видимым во всех местах, где она разбирается. Однако общий шаблон скрывает будущие варианты и тем самым ослабляет проверку компилятора.

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

Перечисления в Rust используются для представления конечного набора альтернативных состояний, включая варианты с разными данными. Для такого типа особенно опасно молча пропустить новое состояние: программа может продолжить работу с неверным предположением о полном наборе случаев.

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

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

Представим перечисление состояния операции с вариантами «готово» и «завершено». Функция обрабатывает только эти варианты, а позже в перечисление добавляется состояние ошибки.

Если match не содержит ветви для ошибки, компилятор сообщает о неисчерпывающем сопоставлении. Если же функция изначально использовала _, ошибка не возникнет, но новое состояние может попасть в неподходящую общую ветвь и привести к неверным действиям.

enum Состояние {
    Готово,
    Завершено,
    Ошибка,
}

fn описание(состояние: Состояние) -> &'static str {
    match состояние {
        Состояние::Готово => "ожидание",
        Состояние::Завершено => "успех",
        // Ошибка не обработана: сопоставление неисчерпывающее.
    }
}

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

Компилятор анализирует шаблоны всех ветвей match и проверяет, существует ли значение перечисления, которое не покрывается ни одной ветвью. Для перечисления нужно покрыть каждый вариант; для вариантов с данными проверяется также соответствие их внутренней структуре.

При добавлении нового варианта прежний полный match становится неполным. Разработчик должен добавить отдельную ветвь, изменить логику обработки или явно указать, что остальные варианты допустимо игнорировать.

Шаблон _ покрывает все значения, которые не совпали с предыдущими ветвями. Это удобно для защитного поведения, логирования или случаев, когда детали остальных вариантов действительно не важны, но такой шаблон отключает полезный сигнал о появлении новых вариантов.

Проверка выполняется статически и не требует отдельного теста для обнаружения пропущенной ветви. При этом компилятор не доказывает, что тело каждой ветви логически корректно: он проверяет только покрытие шаблонами.

Практическое правило: для внутренней модели домена предпочтительнее перечислять варианты явно. _ разумнее оставлять на границах системы или там, где неизвестные и будущие варианты должны обрабатываться единообразно.

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

В сервисе состояние платежа сначала содержало варианты «ожидает» и «оплачен». Обработчик явно сопоставлял оба варианта и запускал разные действия. Позже добавили состояние «отменен».

Первый вариант решения — добавить ветвь для «отменен». Плюс: компилятор сохраняет контроль полноты, а бизнес-логика становится очевидной. Минус: при каждом осознанном расширении перечисления нужно пересматривать обработчики.

Второй вариант — заменить сопоставление на _. Плюс: код перестает требовать изменений при добавлении новых состояний. Минус: отмененный платеж может попасть в логику, предназначенную для неизвестных или несущественных состояний, что создает риск неверного побочного действия.

Выбран первый вариант: в доменной логике все состояния обрабатываются явно, а общий шаблон используется только в диагностическом коде. В результате добавление нового состояния немедленно выявляется компилятором во всех критичных обработчиках.

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

Означает ли неисчерпывающий match, что компилятор проверяет только варианты перечисления?

Нет. Проверка применяется к разным формам шаблонов: булевым значениям, перечислениям, кортежам, структурам, диапазонам и другим поддерживаемым конструкциям. Компилятор анализирует комбинации полей и вариантов, поэтому проверка может учитывать не только внешний тип, но и вложенную структуру значения.

При этом проверка является статическим анализом покрываемости, а не выполнением пользовательских условий. Произвольное условие в if внутри ветви не превращает эту ветвь в доказательство покрытия другого шаблона.

Почему добавление _ может ухудшить сопровождаемость, хотя устраняет ошибку компиляции?

_ сообщает компилятору, что все не перечисленные явно значения обрабатываются одинаково. Если позже появится новый вариант, компилятор не отличит намеренно общий случай от случайно забытого.

Поэтому _ полезен, когда поведение действительно одинаково для всех остальных вариантов, например при игнорировании незначимых событий. В критичной бизнес-логике явные ветви обычно безопаснее, поскольку изменение перечисления становится обязательным поводом проверить последствия.

Что происходит, если новый вариант перечисления добавлен в другом модуле или библиотеке?

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

Явное сопоставление дает более сильный контроль, но может потребовать изменения клиентского кода при расширении типа. Общая ветвь повышает устойчивость к новым вариантам, однако переносит ответственность за корректную обработку неизвестного состояния с компилятора на разработчика и тесты.