Ответ.

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

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

Проблема

Хотя type inference ускоряет работу и делает код лаконичнее, слишком частое или неконтролируемое его использование может приводить к появлению неочевидных ошибок, снижению читаемости и неожиданным performance-проблемам. Не во всех местах компилятор может корректно или однозначно вывести тип. Некоторые конструкции Rust требуют явных аннотаций, иначе код не скомпилируется.

Решение

Rust поддерживает локальное (локальный scope) и контекстуальное выведение типов. Чаще всего вывод типов работает для переменных, значений, возвращаемых функциями, а также для let-выражений внутри функций. Во всех остальных случаях (например, при объявлении структур, сигнатур функций, generic-функций) типы указывать обязательно.

Пример кода:

let x = 10; // x: i32 (по умолчанию)
let y = vec!["hello", "world"]; // y: Vec<&str>

fn add<T: std::ops::Add<Output = T>>(a: T, b: T) -> T {
    a + b
}
let sum = add(2u16, 3u16); // sum: u16

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

Rust делает type inference только внутри ограниченного scope, по выражению справа от знака =.
Аннотации типов обязательны в публичных API, generic-коде, структурах и trait-ах.
Неочевидные или слишком "общие" типы ухудшают читаемость и поддержку кода, даже если компилятор их выводит.

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

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

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

// Будет ошибка:
fn func() { 42 }
// Нужно так:
fn func() -> i32 { 42 }

Можно ли полностью полагаться на type inference при работе с коллекциями или ссылками?

Часто требуется явная аннотация, особенно с mutable/immutable ссылками и сложными generic коллекциями, чтобы избежать неоднозначностей или получить нужный тип.

let data = Vec::new(); // data: Vec<()> — не всегда ожидаемый тип
let numbers: Vec<i32> = Vec::new(); // явно указано

Как type inference работает при использовании замыканий и параметров функций?

Компилятор может вывести типы параметров closure по контексту, но не всегда — иногда потребуется полная аннотация.

let plus_one = |x| x + 1; // ошибка: невозможно вывести тип x
let plus_one = |x: i32| x + 1; // компилируется

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

Полная зависимость от type inference без явных типов в сложном коде ведет к засорению кода ошибками, ухудшению поддержки и читабельности.
Использование Vec::new() или HashMap::new() без явных generic-параметров часто дает неожиданные результаты.

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

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

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

Плюсы:

Меньше кода
Быстрая разработка простого прототипа

Минусы:

Очень плохая документация API
Ошибки при модификации кода
Сложность отладки

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

Другая команда использовала type inference только для локальных переменных в простых выражениях, а во всех публичных API, generic-структурах и функциях всегда указывала типы явно. В итоге поддержка и понимание кода заметно улучшились, снизилось число багов.