Especificadores de fragmento: expr, ident, ty, tt, pat, block

Cuando escribes $x:expr, ese :expr no es decoración: es una instrucción para el analizador sintáctico. Le dice qué clase de fragmento gramatical debe leer y empaquetar bajo el nombre $x. Rust ofrece una docena larga de estos especificadores de fragmento, y cada uno captura una categoría distinta del lenguaje —una expresión, un identificador, un tipo, un patrón, un bloque, un simple árbol de tokens—. Elegir el correcto no es un tecnicismo: determina qué sintaxis acepta tu macro, cómo de opaco queda lo capturado y, sorprendentemente, qué tokens pueden aparecer después del fragmento en el patrón. Dominar este vocabulario es dominar la mitad de macro_rules!.

El vocabulario de especificadores

Un especificador nombra una categoría de la gramática de Rust. Estos son los que se usan a diario:

Un ejemplo que combina varios para generar una constante con nombre, tipo y valor tomados de la invocación:

macro_rules! definir_constante {
    ($nombre:ident : $tipo:ty = $valor:expr) => {
        const $nombre: $tipo = $valor;
    };
}

definir_constante!(LIMITE : u32 = 1_000);
definir_constante!(SALUDO : &str = "hola");

El $nombre:ident exige exactamente un identificador —por eso puede aparecer a la izquierda de const—, $tipo:ty acepta cualquier tipo bien formado y $valor:expr cualquier expresión. Cada uno valida su fragmento en la frontera de la macro: si escribes definir_constante!(3 : u32 = 1), el error salta ahí mismo, porque 3 no es un ident.

Un fragmento es un nodo opaco, no tokens sueltos

Aquí está la propiedad que hace seguras a las macros de Rust y que ya asomó con la precedencia. Cuando el analizador captura un fragmento como expr, ty o pat, lo guarda como un nodo del árbol de sintaxis ya analizado, no como la lista de tokens que lo formaban. A partir de ese momento el fragmento es opaco: la macro no puede mirar dentro, ni partirlo, ni reinterpretarlo. Se comporta como una única unidad atómica, y por eso se inserta con su precedencia y su estructura intactas.

Esta opacidad tiene una consecuencia práctica famosa: las restricciones de continuación. Como un expr puede terminar de muchas formas, el analizador necesita saber sin ambigüedad dónde acaba, así que solo permite que le siga un conjunto reducido de tokens: =>, una coma o un punto y coma. Esto no compila:

// error: `$a:expr` no puede ir seguido de otra `expr`
macro_rules! dos_seguidas {
    ($a:expr $b:expr) => { $a + $b };
}

No hay forma de que el analizador sepa dónde termina $a y empieza $b. La solución es separarlos con uno de los tokens permitidos, típicamente una coma:

macro_rules! suma {
    ($a:expr, $b:expr) => { $a + $b };
}

Cada especificador tiene su propio conjunto de continuadores válidos: tras un ty o un pat pueden ir =>, ,, =, |, ; y unos pocos más; tras un ident puede ir casi cualquier cosa, porque un identificador siempre termina limpio. Conocer estas reglas evita horas de perplejidad ante errores del tipo “no está permitido tras una fragmentación de expresión”.

tt: el comodín que no analiza

tt es el especificador especial. No corresponde a una categoría semántica: captura un único árbol de tokens, que es o bien un token suelto (+, foo, 42) o bien un grupo completo entre (), [] o {} con todo su contenido. Como no impone una interpretación gramatical, casi cualquier cosa puede seguir a un tt, lo que lo convierte en la pieza más flexible del sistema y en la base de dos técnicas centrales: el reenvío de tokens y la recursión de macros (el patrón tt muncher, que iremos viendo).

macro_rules! primero {
    ($primero:tt $($resto:tt)*) => {
        // captura el primer arbol de tokens y descarta el resto
        stringify!($primero)
    };
}

assert_eq!(primero!(a b c), "a");
assert_eq!(primero!((1 + 2) * 3), "(1 + 2)"); // un grupo entre parentesis es UN tt

La flexibilidad de tt es también su debilidad: como no analiza, no valida nada en la frontera y no lleva la protección semántica de un expr. La regla práctica es clara: usa el especificador más específico que sirva —expr, ty, ident— porque da mejores mensajes de error y captura tu intención; reserva tt para cuando de verdad necesitas transportar sintaxis en bruto de una regla a otra.

flowchart TD
inv[Tokens de la invocacion] --> par[El analizador lee segun el especificador]
par --> esp[expr ty pat ident se guardan como nodo opaco]
par --> tt[tt se guarda como arbol de tokens crudo]
esp --> val[Validado en la frontera y con continuacion restringida]
tt --> flex[Casi todo puede seguirle util para reenviar]
style inv fill:#cba6f7,color:#11111b
style esp fill:#a6e3a1,color:#11111b
style tt fill:#f9e2af,color:#11111b