Типы, let и mut в Rust

mut и shadowing - разные вещи

let x = 5 создаёт неизменяемую привязку. Хочешь менять значение в той же ячейке - пиши let mut x. Но есть второй путь: объявить let x ещё раз. Это shadowing, и он заводит новую переменную с тем же именем - старая продолжает жить до конца области видимости, просто до неё больше не дотянуться по имени.

Практическая разница одна и важная: при shadowing можно сменить тип, при mut - нет. Отсюда идиома разбора входных данных: строку читаем, потом перекрываем её же именем уже как число.

// Побочный эффект: если случайно объявить let дважды вместо присваивания, компилятор не ругнётся - переменная просто «перекроется». Это одна из немногих ловушек, которые язык не ловит.

let s = "42";
let s: i32 = s.parse().unwrap();
let mut n = 1;
n += 1; // тип менять нельзя

shadowing

повторный let с тем же именем: новая переменная, можно сменить тип

привязка

связь имени со значением; по умолчанию неизменяемая

Переполнение: паника или обёртка

В C переполнение знакового числа - неопределённое поведение, и это источник дыр. В Rust оно определено, но ведёт себя по-разному: в debug включены проверки, и поток паникует; в release проверки выключены, и результат оборачивается по модулю - 255u8 + 1 даёт 0.

Когда важен конкретный исход, его пишут явно: checked_add вернёт Option (None при переполнении), saturating_add упрётся в границу типа, wrapping_add честно обернётся. Такой код одинаково работает в обеих сборках и читается без догадок.

// Отсюда же ответ на вопрос про as: 300i32 as u8 == 44, потому что as просто берёт младшие биты. Если потеря данных недопустима - TryFrom и разбор Err.

let x: u8 = 255;
x.checked_add(1);    // None
x.saturating_add(1); // 255
x.wrapping_add(1);   // 0

overflow-checks

проверки переполнения: включены в debug, выключены в release

TryFrom

преобразование с проверкой; возвращает Result вместо усечения

const, static и блоки-выражения

const это значение, которое подставляется в каждое место использования: собственного адреса у него нет, дублирование нормально. static - одна ячейка с фиксированным адресом и лайфтаймом 'static, на неё можно взять ссылку. Изменяемый static требует unsafe, потому что синхронизации у него нет.

Ещё одна базовая деталь: блок в Rust - выражение. Значение последней строки без точки с запятой становится значением блока и функции. Поставил точку с запятой - получил (), и компилятор пожалуется уже там, где результат попробуют использовать.

const MAX: u32 = 100;
static NAME: &str = "сеньорчик";
let y = { let z = 2; z * 10 }; // 20

const

константа, подставляемая значением в места использования

static

единственная ячейка с адресом и лайфтаймом 'static

Как отвечать: «Что будет при переполнении i32 и как это контролировать?»

Переполнение в Rust определено, это не UB как в C. В debug-сборке включены overflow-checks, и поток паникует. В release проверки выключены, и результат оборачивается по модулю. Если поведение важно для логики, я не полагаюсь на профиль сборки, а пишу явно: checked_add, когда переполнение - ошибка и её надо обработать, saturating_add, когда нужно упереться в границу, wrapping_add, когда обёртка это и есть намерение - например, в хешах или счётчиках.

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

На чём валятся

• −Говорят, что переполнение в release это UB (undefined behavior). Нет: поведение определено, результат оборачивается по модулю.
• −Путают shadowing с mut. Второй let создаёт новую переменную и разрешает сменить тип, mut только меняет значение.
• −Считают, что as безопасно приводит числа. Он молча отбрасывает старшие биты; проверку даёт TryFrom.
• −Забывают, что лишняя точка с запятой в конце функции превращает возврат в ().
• −Не могут объяснить разницу const и static, а вопрос про static mut и unsafe идёт следом почти всегда.