Answer.

Background

In the Rust language, as in many modern programming languages, a type inference system is implemented that helps programmers save time and reduce the amount of duplicate code. It has been present in Rust almost from the beginning, aiming to simplify static typing without the need to explicitly specify the variable type in every instance.

The Issue

Although type inference speeds up work and makes the code more concise, excessive or uncontrolled use of it can lead to non-obvious errors, decreased readability, and unexpected performance issues. The compiler cannot deduce the type correctly or unambiguously in all places. Some Rust constructs require explicit annotations; otherwise, the code will not compile.

The Solution

Rust supports local (local scope) and contextual type inference. Most often, type inference works for variables, values returned by functions, and also for let-expressions within functions. In all other cases (for example, when declaring structs, function signatures, generic functions), types must be explicitly specified.

Example code:

let x = 10; // x: i32 (default)
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

Key features:

Rust performs type inference only within a limited scope, on the right side of the = sign.
Type annotations are mandatory in public APIs, generic code, structs, and traits.
Non-obvious or too "general" types hurt the readability and maintainability of the code, even if the compiler can infer them.

Trick Questions.

Can the Rust compiler infer the type of a function if the return type is not specified explicitly?

No, in the function signature, the return type must always be explicitly stated; otherwise, a compilation error will occur.

// Will give an error:
fn func() { 42 }
// It needs to be:
fn func() -> i32 { 42 }

Can you fully rely on type inference when working with collections or references?

Explicit annotation is often required, especially with mutable/immutable references and complex generic collections, to avoid ambiguities or to get the desired type.

let data = Vec::new(); // data: Vec<()> — not always the expected type
let numbers: Vec<i32> = Vec::new(); // explicitly stated

How does type inference work when using closures and function parameters?

The compiler can infer the types of closure parameters from context, but not always — sometimes full annotation will be required.

let plus_one = |x| x + 1; // error: cannot infer type of x
let plus_one = |x: i32| x + 1; // compiles

Common Errors and Anti-Patterns

Full reliance on type inference without explicit types in complex code leads to cluttering the code with errors, worsening maintainability and readability.
Using Vec::new() or HashMap::new() without explicit generic parameters often yields unexpected results.

Real-Life Example

Negative Case

A developer wrote an API function with completely unannotated parameters and local variables without specifying types — the whole code relied only on type inference. The team encountered numerous custom errors and confusion: it was unclear what types were expected as parameters and what the function actually returned.

Pros:

Less code
Fast prototyping of simple applications

Cons:

Very poor API documentation
Errors when modifying the code
Difficulty debugging

Positive Case

Another team used type inference only for local variables in simple expressions, and always explicitly stated types in all public APIs, generic structs, and functions. As a result, the support and understanding of the code significantly improved, and the number of bugs decreased.