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

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

Это поведение относится к настройкам профиля сборки, а не к отдельному типу. Его можно изменить настройкой overflow-checks, а для явного и независимого от профиля поведения следует использовать методы вроде checked_add, wrapping_add или saturating_add.

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

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

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

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

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

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

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

Для знакового целого заданной разрядности арифметический результат имеет конечный диапазон. Если результат выходит за него, обычная операция в отладочной сборке вызывает панику при включённых проверках переполнения, а в релизной сборке по умолчанию выполняется оборачивание.

Например:

fn main() {
    let max = i8::MAX;
    let result = max.wrapping_add(1);
    println!("{result}");
}

Здесь результат явно оборачивается независимо от профиля сборки: для i8 после 127 получается -128. Метод checked_add вместо этого возвращает Option, overflowing_add возвращает результат вместе с флагом переполнения, а saturating_add ограничивает результат максимальным или минимальным значением.

Важно отличать обычное выполнение от вычисления констант. Переполнение, обнаруженное при компиляции константного выражения, не превращается в разрешённое релизное оборачивание: такое выражение обычно считается ошибочным на этапе компиляции. Для константного вычисления с намеренным оборачиванием нужно использовать явную wrapping-операцию.

Настройка overflow-checks может включать или отключать проверки в конкретном профиле, поэтому слово «обычно» существенно. Надёжный код выбирает операцию по бизнес-смыслу, а не рассчитывает на debug- или release-режим.

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

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

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

Выбрано checked_add с преобразованием None в ошибку валидации. Такое решение явно выражает ожидаемое поведение, одинаково работает в разных профилях и позволяет вернуть клиенту понятную ошибку вместо паники или повреждения дальнейших вычислений.

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

Всегда ли переполнение в релизной сборке разрешено?

Нет. Речь идёт о поведении по умолчанию для обычной арифметики при стандартных настройках релизного профиля. Настройка overflow-checks может включить проверки, поэтому корректный ответ должен учитывать конфигурацию сборки.

Кроме того, явные методы checked_*, wrapping_*, saturating_* и overflowing_* задают собственную семантику и не зависят от того, включены ли проверки профиля.

Одинаково ли ведут себя переполнение во время выполнения и переполнение константы?

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

Если оборачивание в константном вычислении является намеренным, его нужно выразить явной wrapping-операцией, а не рассчитывать на релизный режим.

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

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

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