Closures como parámetros y retornos: impl Fn, dyn Fn y Box

Un closure es un valor, pero un valor con una peculiaridad: su tipo no tiene nombre. El compilador fabrica una struct anónima por cada closure, y tú no puedes escribir ese tipo en una firma. Entonces, ¿cómo se pasa un closure a una función, o se devuelve de ella? Rust ofrece dos caminos, los mismos dos que rigen todo el polimorfismo del lenguaje: el estático —impl Fn y genéricos con bound Fn, que monomorfizan y se inlinan— y el dinámico —&dyn Fn, Box<dyn Fn>, que pasan por una vtable—. Elegir entre ellos es elegir entre velocidad y flexibilidad, y saber cuándo cada uno es la respuesta correcta separa el código idiomático del que pelea con el compilador.

Recibir un closure: tres formas

Como el tipo del closure no se puede nombrar, lo describes por el trait que implementa. La vía estática usa un parámetro genérico con bound, o su azúcar impl Fn:

// Genérico explícito: F es un tipo concreto elegido en cada llamada.
fn aplica<F: Fn(i32) -> i32>(f: F, x: i32) -> i32 { f(x) }

// Azúcar impl Trait: idéntico, más breve.
fn aplica2(f: impl Fn(i32) -> i32, x: i32) -> i32 { f(x) }

let doble = |n| n * 2;
println!("{}", aplica(doble, 21)); // 42

Ambas formas monomorfizan: por cada tipo concreto de closure que le pases, el compilador genera una copia especializada de aplica, con la llamada f(x) normalmente inlinada. Coste de abstracción: cero. La vía dinámica, en cambio, describe el closure tras un puntero a dyn Fn:

// &dyn Fn: presta el closure a traves de un trait object.
fn aplica_dyn(f: &dyn Fn(i32) -> i32, x: i32) -> i32 { f(x) }

let doble = |n| n * 2;
println!("{}", aplica_dyn(&doble, 21)); // 42

Aquí aplica_dyn se compila una sola vez; la llamada f(x) pasa por la vtable del closure (despacho dinámico, nivel 15). No se inlina, pero el binario no crece por cada closure distinto.

Guardar un closure: hace falta dyn

El caso donde el dinámico deja de ser una opción y pasa a ser una necesidad: almacenar closures de tipos distintos juntos, o guardarlos en una struct sin parametrizarla. Un Vec exige un único tipo, y dos closures distintos tienen tipos distintos:

// NO compila: cada closure tiene su propio tipo anonimo.
// let acciones = vec![|x| x + 1, |x| x * 2];

// Si compila: Box<dyn Fn> les da un tipo comun de tamano fijo.
let acciones: Vec<Box<dyn Fn(i32) -> i32>> = vec![
    Box::new(|x| x + 1),
    Box::new(|x| x * 2),
];
for a in &acciones {
    println!("{}", a(10)); // 11, luego 20
}

Box<dyn Fn(i32) -> i32> borra el tipo concreto y lo aloja en el heap, dando a todos los closures el mismo tipo estático y el mismo tamaño —un puntero gordo—, requisito para meterlos en una colección homogénea. El mismo Box<dyn Fn> es lo que guardas en una struct cuando no quieres volverla genérica:

struct Boton {
    al_pulsar: Box<dyn Fn()>,   // callback poseído, tipo borrado
}

Devolver un closure

Devolver un closure choca con el mismo muro: no puedes escribir su tipo. Si la función devuelve siempre el mismo closure, -> impl Fn basta y es la opción de coste cero:

fn multiplicador(factor: i32) -> impl Fn(i32) -> i32 {
    move |x| x * factor
}

let por3 = multiplicador(3);
println!("{}", por3(10)); // 30

impl Fn significa “devuelvo algún tipo concreto que implementa Fn, siempre el mismo, pero no te digo cuál”. El problema aparece cuando distintas ramas devuelven closures distintos: cada uno tiene su tipo, e impl Fn exige un tipo único. Ahí entra Box<dyn Fn>:

fn operacion(nombre: &str) -> Box<dyn Fn(i32) -> i32> {
    match nombre {
        "inc"   => Box::new(|x| x + 1),
        "doble" => Box::new(|x| x * 2),
        _       => Box::new(|x| x),
    }
}

Cada rama produce un closure de tipo diferente; solo tras borrarlos con dyn comparten un tipo de retorno común. Es el mismo patrón fábrica que viste con los trait objects, aplicado a funciones.

flowchart TB
q1[Necesitas un solo tipo de closure] -->|si y quieres maxima velocidad| est[Estatico con impl Fn o generico]
q1 -->|no varian los tipos o los guardas juntos| din[Dinamico con Box dyn Fn]
est --> e1[Monomorfiza e inlina coste cero]
est --> e2[Un tipo por llamada crece el binario]
din --> d1[Una vtable y heap heterogeneo posible]
din --> d2[Indireccion sin inlining]
style est fill:#a6e3a1,color:#11111b
style din fill:#89b4fa,color:#11111b

El trade-off

Las dos vías son las mismas del dispatch estático frente al dinámico, ahora sobre closures:

La heurística: usa estático por defecto —impl Fn al recibir, impl Fn al devolver un tipo único— porque es gratis. Cambia a dinámico solo cuando lo necesitas de verdad: closures de tipos distintos en la misma colección, un callback guardado en una struct que no quieres parametrizar, o un retorno que varía por rama. No es “rápido contra lento”, es “homogéneo y monomorfizable” contra “heterogéneo y de tipo borrado”.