Respuesta.

Historia de la cuestión

En el lenguaje Rust, al igual que en muchos lenguajes de programación modernos, se implementa un sistema de inferencia de tipos que ayuda a los programadores a ahorrar tiempo y reducir la cantidad de código duplicado. Apareció en Rust prácticamente desde el principio para facilitar la tipificación estática sin necesidad de especificar explícitamente el tipo de variable en cada caso.

Problema

Aunque la inferencia de tipos acelera el trabajo y hace que el código sea más conciso, un uso excesivo o incontrolado de ella puede llevar a errores poco evidentes, disminuir la legibilidad y causar problemas de rendimiento inesperados. No en todos los lugares el compilador puede inferir el tipo de manera correcta o unívoca. Algunas construcciones de Rust requieren anotaciones explícitas, de lo contrario, el código no se compilará.

Solución

Rust soporta la inferencia de tipos local (en el ámbito local) y contextual. Más comúnmente, la inferencia de tipos funciona para variables, valores devueltos por funciones y también para expresiones let dentro de funciones. En todos los demás casos (por ejemplo, al declarar estructuras, firmas de funciones y funciones genéricas), es obligatorio especificar los tipos.

Ejemplo de código:

let x = 10; // x: i32 (por defecto)
let y = vec!["hola", "mundo"]; // 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

Características clave:

Rust realiza la inferencia de tipos solo dentro de un ámbito limitado, en la expresión a la derecha del signo =.
Las anotaciones de tipos son obligatorias en las APIs públicas, código genérico, estructuras y rasgos.
Tipos poco evidentes o demasiado "generales" disminuyen la legibilidad y el mantenimiento del código, incluso si el compilador los infiere.

Preguntas trick.

¿Puede el compilador de Rust inferir el tipo de una función si no se especifica explícitamente el valor de retorno?

No, en la firma de la función, el tipo del valor de retorno siempre debe especificarse de manera explícita, de lo contrario, habrá un error de compilación.

// Habrá un error:
fn func() { 42 }
// Debe ser así:
fn func() -> i32 { 42 }

¿Se puede confiar completamente en la inferencia de tipos al trabajar con colecciones o referencias?

A menudo se requiere una anotación explícita, especialmente con referencias mutables/inmutables y colecciones genéricas complejas, para evitar ambigüedades o para obtener el tipo deseado.

let data = Vec::new(); // data: Vec<()> — tipo no siempre esperado
let numbers: Vec<i32> = Vec::new(); // especificado explícitamente

¿Cómo funciona la inferencia de tipos al usar cierres y parámetros de funciones?

El compilador puede inferir los tipos de los parámetros de cierre según el contexto, pero no siempre; a veces se requerirá una anotación completa.

let plus_one = |x| x + 1; // error: no se puede inferir el tipo de x
let plus_one = |x: i32| x + 1; // compila

Errores típicos y anti-patrones

La dependencia total de la inferencia de tipos sin tipos explícitos en código complejo lleva a la contaminación del código con errores, disminuyendo el mantenimiento y la legibilidad.
Usar Vec::new() o HashMap::new() sin parámetros genéricos explícitos a menudo da resultados inesperados.

Ejemplo de la vida real

Caso negativo

Un desarrollador escribió una función de API con parámetros completamente no anotados y variables locales sin especificar tipos: todo el código dependía únicamente de la inferencia de tipos. El equipo se enfrentó a muchos errores personalizados y confusión: no estaba claro qué tipos esperaban los parámetros y qué realmente devolvía la función.

Ventajas:

Menos código
Desarrollo rápido de un prototipo simple

Desventajas:

Documentación API muy deficiente
Errores al modificar el código
Complejidad en la depuración

Caso positivo

Otro equipo utilizó la inferencia de tipos únicamente para variables locales en expresiones simples, y en todas las APIs públicas, estructuras genéricas y funciones, siempre especificaron los tipos de manera explícita. Como resultado, el mantenimiento y la comprensión del código mejoraron significativamente, y se redujo el número de errores.