Casos reales: reimplementar vec!, un mini-DSL y cuándo usar macros

Ya tienes las piezas: patrones sobre tokens, especificadores de fragmento, repetición e higiene. Toca ensamblarlas en código que de verdad escribirías. Reconstruiremos vec! tal como es en realidad —con sus tres reglas—, escribiremos un mini-DSL que genera un enum entero junto a su impl, algo que ninguna función podría hacer, y cerraremos con el juicio más importante de todos: cuándo una macro declarativa es la herramienta correcta, y cuándo estás usando un martillo para algo que pedía un destornillador. Porque la maestría con las macros no consiste en escribir muchas, sino en saber reconocer las pocas ocasiones en que son la respuesta.

vec! por dentro: las tres reglas

El vec! de la biblioteca estándar no es una macro monolítica: son tres reglas que cubren tres formas de invocarlo. La versión de enseñanza, fiel en estructura a la real, es esta:

macro_rules! vector {
    // Regla 1: sin argumentos, un Vec vacio.
    () => {
        Vec::new()
    };
    // Regla 2: un elemento repetido n veces, como vec![0; 5].
    ($elem:expr; $n:expr) => {
        ::std::vec::from_elem($elem, $n)
    };
    // Regla 3: una lista de elementos, con coma final opcional.
    ($( $x:expr ),+ $(,)?) => {{
        let mut v = Vec::new();
        $( v.push($x); )+
        v
    }};
}

fn main() {
    let a: Vec<i32> = vector![];        // regla 1
    let b = vector![7; 3];              // regla 2  ->  [7, 7, 7]
    let c = vector![1, 2, 3];           // regla 3
    assert_eq!((a.len(), b, c), (0, vec![7, 7, 7], vec![1, 2, 3]));
}

Observa la selección de regla por forma sintáctica. La 1 no tiene tokens; la 2 se distingue por el punto y coma que separa elemento y cuenta; la 3 empareja una lista separada por comas con + —una o más— y su $(,)? para la coma final. El compilador prueba de arriba abajo y elige la primera que cuadra. Ese despacho por sintaxis, imposible en una función, es justo lo que hace de vec! una macro. La real delega en from_elem y en primitivas internas para la repetición eficiente, pero el esqueleto es exactamente este.

Un mini-DSL: generar código, no solo valores

El verdadero superpoder aparece cuando una macro genera ítems —definiciones enteras—, no meras expresiones. Aquí ninguna función alcanza: una función produce valores en ejecución, jamás un enum o un impl nuevos. Este pequeño DSL declara un enum y le adosa un método que devuelve el nombre de cada variante como texto:

macro_rules! enum_nombrado {
    ($nombre:ident { $( $variante:ident ),+ $(,)? }) => {
        #[derive(Debug, Clone, Copy, PartialEq)]
        enum $nombre {
            $( $variante ),+
        }

        impl $nombre {
            fn nombre(&self) -> &'static str {
                match self {
                    $( $nombre::$variante => stringify!($variante), )+
                }
            }

            fn todas() -> &'static [$nombre] {
                &[ $( $nombre::$variante ),+ ]
            }
        }
    };
}

enum_nombrado!(Color { Rojo, Verde, Azul });

fn main() {
    assert_eq!(Color::Verde.nombre(), "Verde");
    assert_eq!(Color::todas().len(), 3);
}

Una sola invocación generó un enum con tres variantes, un impl con un match exhaustivo sobre ellas y un inventario de todas. La macro stringify! convierte el token del identificador en su texto, y la repetición $()+ teje a la vez las variantes, los brazos del match y los elementos del array. Escribir esto a mano para diez enums sería repetición pura; con la macro, la fuente de verdad es la lista de variantes y todo lo demás se deriva. Ese es el nicho donde una macro declarativa brilla: código estructuralmente idéntico que solo cambia en los nombres.

Cuándo una macro es la herramienta correcta

Aquí está el juicio que separa al que conoce las macros del que las domina. Ordena tus herramientas de la más simple a la más pesada y baja solo cuando la anterior no llega:

La frontera decisiva está entre las dos últimas. macro_rules! es un emparejador de patrones: reescribe según plantillas, pero no computa. No sabe hacer aritmética de verdad, no puede recorrer los campos de un tipo, no toma decisiones basadas en el contenido de un fragmento —solo en su forma—, y su recursión tiene un límite. En cuanto necesitas razonar sobre el código en vez de estamparlo —inspeccionar los campos de un struct para un derive, validar contra un esquema, generar a partir de un fichero externo—, macro_rules! se queda corta y toca una macro procedural, que es código Rust ejecutándose en compilación sobre los tokens como datos. La regla final: usa una función si puedes, una macro declarativa si la interfaz lo exige, y una procedural solo cuando de verdad haga falta programar la generación.

flowchart TD
start[Que necesitas abstraer] --> val[Comportamiento sobre valores]
val -->|si| fn[Usa una funcion]
val -->|no| ty[Lo mismo para muchos tipos]
ty -->|si| gen[Usa genericos y traits]
ty -->|no| syn[Variadica o generar items o sintaxis]
syn -->|si| decl[Basta emparejar patrones]
syn -->|no| fn
decl -->|si| mr[Usa macro_rules]
decl -->|no, hay que inspeccionar tokens| proc[Usa una macro procedural]
style fn fill:#a6e3a1,color:#11111b
style mr fill:#cba6f7,color:#11111b
style proc fill:#89b4fa,color:#11111b