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

Выражение if должно иметь один согласованный тип результата. Rust проверяет типы всех возвращающих значение ветвей и применяет допустимое приведение типов; если согласовать их нельзя, программа не скомпилируется. Если ветви не возвращают полезное значение, их типом обычно является ().

Ветка else обязательна, когда результат if используется как значение: без неё отсутствующая ветвь трактуется как ().

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

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

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

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

Если одна ветвь возвращает целое число, а другая — строку, Rust не может выбрать один тип выражения автоматически. Даже если в конкретном запуске выполнится только одна ветвь, компилятор обязан проверить обе возможные траектории выполнения.

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

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

Тип if определяется по его ветвям. Условие должно иметь тип bool, затем Rust проверяет блок then и блок else; значением блока считается его последнее выражение без завершающей точки с запятой.

fn label(ok: bool) -> String {
    if ok {
        "успех".to_owned()
    } else {
        String::from("ошибка")
    }
}

fn main() {
    let value = if 2 > 1 { 10 } else { 20 };
    println!("{value}");
}

В первом if обе ветви имеют тип String, поэтому результат функции корректен. Во втором обе ветви имеют тип i32, который выводится для переменной value.

Разные исходные типы иногда могут быть согласованы через разрешённое Rust приведение типов, например при переходе от &String к &str в подходящем контексте. Это не означает, что произвольные значения автоматически преобразуются друг в друга: для чисел или несвязанных структурных типов обычно требуется явное преобразование.

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

Особый случай — расходящиеся выражения типа !, например panic! или return. Они не завершаются обычным значением и могут использоваться в месте ветви любого ожидаемого типа, поэтому фактически не мешают согласованию остальных ветвей.

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

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

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

Можно использовать Box<dyn Trait>, если оба результата реализуют общий trait. Плюс — расширяемость и единый интерфейс; минусы — динамическая диспетчеризация, ограничения object safety и менее явная модель данных.

Можно вернуть Result<УспешноеЗначение, Ошибка>. Это выбранное решение, потому что успех и ошибка — разные семантические исходы операции, а Result явно отражает их в типе, сохраняет статическую диспетчеризацию и заставляет вызывающий код обработать ошибку.

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

Обязательна ли ветка else, если if используется внутри функции, возвращающей значение?

Не всегда: если отсутствующая ветвь фактически должна дать (), функция может возвращать (), либо результат if может использоваться только ради побочного эффекта. Но если ожидается конкретный непустой тип, отсутствие else приводит к несогласованию типов, поскольку альтернативный результат равен ().
Считаются ли ветви совместимыми, если они возвращают разные ссылочные типы?

Иногда да, если между ними существует разрешённое неявное приведение в позиции проверки типа. Например, ссылка на конкретный тип может быть приведена к ссылке на trait-объект при подходящих условиях. Однако Rust не выполняет произвольное преобразование и не ищет общий тип так же свободно, как языки с динамической типизацией.
Почему ветвь с panic! не заставляет выбирать общий тип с !?

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