Ответ

Rust предоставляет удобные стандартные средства для преобразования строк в числа через трейт FromStr. Наиболее часто используется метод .parse::<T>(), который можно вызвать на строках и срезах.

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

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

Проблема

.parse::<T>() возвращает результат типа Result<T, ParseIntError> (или аналогичный для других типов), что вынуждает явно обрабатывать неудачи. Частая ошибка — игнорировать возможность ошибки, использовать unwrap() без анализа, что грозит падением программы при некорректном вводе данных, а не корректным сообщением об ошибке.

Решение

Для преобразования строк используют метод parse. Его сигнатура:

let num: i32 = "42".parse().unwrap();

Но правильнее — обрабатывать ошибку:

let s = "abc";
match s.parse::<i32>() {
    Ok(n) => println!("Получено число: {}", n),
    Err(e) => println!("Ошибка парсинга: {e}"),
}

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

Для каждого числового типа реализован FromStr, но точные ограничения неявны: пробелы, знаки, переполнение учитываются по-разному
Ошибки возвращаются как Result, а не через панику или исключение
Любой тип с реализацией FromStr (включая пользовательские) может быть целью .parse()

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

Можно ли использовать parse без указания типа результата?

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

Что произойдет, если попытаться спарсить строку с нецифровым содержимым в число?

Метод вернет ошибку (Err(...)), не вызовет панику. Ошибка реализует трейт Debug, что удобно для вывода.

let num: Result<u32, _> = "not_a_number".parse();
assert!(num.is_err());

Можно ли использовать unwrap после parse, если уверены в содержимом?

Технически можно, но это анти-паттерн. Если строка неожиданно невалидна, программа аварийно завершится.

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

Использование unwrap() без обработки ошибок
Неиспользование trim перед преобразованием, если ввод от пользователя
Ошибка типа при parse (parse::<String>()) вместо целевого числового типа

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

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

Консольная утилита читает число от пользователя и использует .parse().unwrap(). При случайном неверном вводе программа внезапно падает, пользователь не понимает причину.

Плюсы:

Проще код

Минусы:

Потенциальный выход из программы, плохой пользовательский опыт

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

Ввод вначале очищается от пробелов, а parse используется в сценарии с match или если нужно — map_err для возвращения своей ошибки. Ошибки обрабатываются корректно, выдаётся отчётливое сообщение об ошибке.

Плюсы:

Программа не падает на неверном вводе; ошибки информативны
Код безопаснее и очевиднее поддерживать

Минусы:

Чуть больше кода при работе с вводом