La pereza: nada ocurre hasta que se consume

Escribes v.iter().map(carisimo).filter(raro) y no pasa absolutamente nada. Ni una llamada a carisimo, ni una comprobación de raro. Has descrito una transformación, pero no la has ejecutado: los iteradores de Rust son perezosos (lazy). Un adaptador no computa; construye —envuelve el iterador anterior en uno nuevo y se aparta—. El trabajo real duerme hasta que algo, al final de la cadena, empieza a tirar de los valores. Esta pereza no es un defecto ni una optimización menor: es la propiedad que hace que encadenar diez adaptadores no cueste diez pasadas, y que un iterador infinito sea una herramienta cotidiana en vez de un cuelgue seguro.

Encadenar construye, no ejecuta

Un adaptador como map no aplica la función a nada. Devuelve un valor de tipo Map<I, F>: una estructura que guarda el iterador de origen I y la clausura F, sin llamarla ni una vez. filter devuelve un Filter, take un Take, y así con todos. Encadenar adaptadores es apilar envoltorios, una operación puramente estructural:

let it = (1..=3).map(|x| {
    println!("procesando {x}");   // efecto visible... si se ejecutara
    x * 2
});
println!("iterador construido");
// Salida hasta aqui: solo "iterador construido".
// map no ha llamado a la clausura ni una vez.

El println! de dentro del map no se imprime. Has fabricado un iterador que sabe cómo duplicar y anunciar, pero que no lo ha hecho. La descripción de la computación y su ejecución son dos momentos distintos, y hasta aquí solo ocurrió el primero.

El consumidor tira y el valor fluye

El trabajo empieza cuando un consumidor entra en escena: collect, sum, for, count… Un consumidor llama a next en la cabeza de la cadena, y esa llamada se propaga hacia atrás hasta la fuente:

let v: Vec<i32> = it.collect();
// AHORA si: se imprime "procesando 1", "procesando 2", "procesando 3"
// y v queda [2, 4, 6].

Conviene ver la dirección exacta del movimiento. La demanda viaja hacia atrás: collect pide a filter, filter pide a map, map pide al rango. El valor viaja hacia adelante: el rango produce un 1, map lo dobla a 2, filter decide, y si pasa llega a collect. Y —esto es lo crucial— fluye un solo elemento cada vez por toda la tubería. No hay un vector intermedio con todos los map hechos y luego otro con los filter: cada valor recorre la cadena entera antes de que el siguiente empiece.

let suma: i64 = (1..=1_000_000)
    .map(|x| x * 2)
    .filter(|x| x % 3 == 0)
    .sum();
// Ni un solo Vec de un millon de elementos se materializa:
// los valores pasan de uno en uno por toda la cadena.

Ese comportamiento tiene nombre y recompensa: la fusión. Como toda la cadena es perezosa y está monomorfizada, el compilador la ve entera en el punto de consumo y genera el mismo código máquina que habrías escrito con un bucle a mano. La cadena declarativa de arriba y este bucle imperativo son, para el compilador, indistinguibles:

let mut suma: i64 = 0;
for x in 1..=1_000_000 {
    let y = x * 2;              // lo que hacia map
    if y % 3 == 0 {            // lo que decidia filter
        suma += y;             // lo que acumulaba sum
    }
}

Escribes la versión legible y pagas el precio de la ilegible: cero abstracción sobrante. Esa es la promesa de “abstracción de coste cero” cumplida, esta vez, sobre los iteradores.

must_use: el compilador vigila la pereza

La pereza tiene una trampa clásica: construir una cadena y olvidar consumirla. Como el iterador no hace nada por sí mismo, ese olvido significa que tu trabajo nunca ocurre. Rust lo sabe y marca Iterator como #[must_use]:

(1..=3).map(|x| println!("{x}"));  // WARNING: iterador sin usar, no hace nada

El compilador te avisa de que has descrito una computación y la has tirado a la basura sin ejecutarla. Si querías el efecto, faltó un consumidor —un for, un .collect(), un .count() o el idiomático .for_each(...)—.

Iteradores infinitos, domados por la pereza

Si los adaptadores ejecutaran al vuelo, un iterador sin fin sería un cuelgue garantizado. Como no ejecutan, puedes describir lo infinito y recortarlo después:

let primeros_cinco: Vec<u64> = (0..)          // rango infinito: 0, 1, 2, ...
    .map(|n| n * n)                           // cuadrados, perezoso
    .take(5)                                  // corta en cinco, perezoso
    .collect();                               // [0, 1, 4, 9, 16]

(0..) promete infinitos naturales, pero take(5) solo pedirá cinco next, así que la fuente solo produce cinco valores. La pereza convierte “infinito” en algo con lo que se programa a diario: describes el todo y consumes la parte.

flowchart RL
cons[collect pide el siguiente valor] --> filt[filter lo pide al anterior]
filt --> mapa[map lo pide al anterior]
mapa --> src[El rango produce un numero]
src --> tmap[map lo transforma]
tmap --> tfil[filter lo acepta o lo descarta]
tfil --> tcon[collect lo acumula]
style cons fill:#cba6f7,color:#11111b
style src fill:#a6e3a1,color:#11111b
style tcon fill:#89b4fa,color:#11111b