Const generics: tipos parametrizados por valores

Un genérico ordinario abstrae sobre tipos: Vec<T> funciona para cualquier T. Pero hay una segunda clase de genéricos que abstrae sobre valores: números, bool o char fijados en compilación. Se llaman const generics, y su forma es const N: usize. Con ellos, el tamaño de un array deja de ser un dato de ejecución y pasa a formar parte del tipo: [f64; 3] y [f64; 4] son tipos distintos, tan distintos como i32 y String. Esto desbloquea algo que antes exigía macros o unsafe: estructuras de tamaño fijo cuyas dimensiones el compilador comprueba —y hace cuadrar— por ti.

Genéricos sobre valores

La sintaxis añade const N: usize a la lista de parámetros, y a partir de ahí N es un valor utilizable donde se espera una constante, señaladamente como longitud de un array:

struct Vector<const N: usize> {
    datos: [f64; N],
}

impl<const N: usize> Vector<N> {
    fn ceros() -> Vector<N> {
        Vector { datos: [0.0; N] }
    }
    fn dimension(&self) -> usize {
        N                       // la constante es accesible como valor
    }
}

fn main() {
    let a = Vector::<3>::ceros();   // tipo Vector<3>
    let b = Vector::<4>::ceros();   // tipo Vector<4>, distinto
    assert_eq!(a.dimension(), 3);
    // let _ = a == b;              // ni siquiera son el mismo tipo
}

Vector<3> y Vector<4> son tipos separados con disposiciones de memoria distintas —24 y 32 bytes—. El valor N habita el tipo: es información conocida en compilación, no un campo que se lea en ejecución.

use std::mem::size_of;

fn main() {
    assert_eq!(size_of::<Vector<3>>(), 24);   // 3 por 8 bytes
    assert_eq!(size_of::<Vector<4>>(), 32);   // 4 por 8 bytes, y es otro tipo
}

Que el tamaño viva en el tipo tiene una consecuencia práctica enorme: puedes tener arrays en la pila, sin asignar en el montón, con la longitud garantizada por el compilador. Donde antes recurrías a un Vec —longitud dinámica, un puntero y una comprobación de límites en cada acceso— ahora usas [T; N], con el tamaño fijo y conocido, y a menudo el optimizador elimina las comprobaciones de límites porque puede probarlas.

El tamaño en el tipo: matrices que cuadran

Lo mismo vale para funciones. Una que sume dos arrays exige, por su firma, que ambos midan lo mismo:

fn suma<const N: usize>(a: [i32; N], b: [i32; N]) -> [i32; N] {
    let mut r = [0; N];
    let mut i = 0;
    while i < N {
        r[i] = a[i] + b[i];
        i += 1;
    }
    r
}

fn main() {
    let _ = suma([1, 2, 3], [4, 5, 6]);   // OK, ambos [i32; 3]
    // let _ = suma([1, 2, 3], [4, 5]);   // ERROR: los tamanos N no coinciden
}

El desajuste de longitudes no es un panic: es que no existe un N que satisfaga la firma con [i32; 3] y [i32; 2] a la vez. La joya de la corona es la multiplicación de matrices, donde la dimensión interna debe casar:

struct Matriz<const R: usize, const C: usize> {
    datos: [[f64; C]; R],
}

impl<const R: usize, const K: usize> Matriz<R, K> {
    // R por K multiplicada por K por C da R por C: las dimensiones cuadran en el tipo
    fn por<const C: usize>(&self, otra: &Matriz<K, C>) -> Matriz<R, C> {
        let mut datos = [[0.0; C]; R];
        for i in 0..R {
            for j in 0..C {
                for k in 0..K {
                    datos[i][j] += self.datos[i][k] * otra.datos[k][j];
                }
            }
        }
        Matriz { datos }
    }
}

Multiplicar una Matriz<2, 3> por una Matriz<3, 4> compila y da una Matriz<2, 4>; multiplicarla por una Matriz<5, 4> no compila, porque la K de la izquierda —3— no es la K de la derecha —5—. El álgebra lineal impone que las dimensiones internas coincidan, y aquí esa regla la vigila el compilador, gratis, antes de ejecutar una sola multiplicación.

flowchart LR
a[Matriz R por K] --> m[Producto]
b[Matriz K por C] --> m
k[La dimension interna K debe coincidir o no compila] --> m
m --> r[Matriz R por C]
style m fill:#cba6f7,color:#11111b
style r fill:#a6e3a1,color:#11111b
style k fill:#f38ba8,color:#11111b

Lo que puedes y lo que aún no

Los const generics tienen fronteras nítidas, y conocerlas evita frustración.

Qué tipos valen como parámetro. En estable, un parámetro const debe ser de un tipo entero, bool o char. No puedes aún parametrizar por un tipo propio —un enum o un struct— sin la feature inestable adt_const_params.

Qué puedes calcular con ellos. Puedes pasar una constante y usarla como longitud, [T; N], pero no operar con ella en posición de tipo. Esto todavía no compila en estable:

// Requiere la feature inestable generic_const_exprs
// fn empujar<const N: usize>(a: [i32; N], x: i32) -> [i32; N + 1] {
//     // ... construir un array de tamano N + 1 ...
// }

La aritmética de constantes en los tipos —N + 1, R * C— vive tras generic_const_exprs, aún inestable por los problemas que plantea al comprobador. Por eso el ejemplo de matrices se diseñó con cuidado para no calcular: Matriz<R, K> por Matriz<K, C> da Matriz<R, C> reutilizando los parámetros tal cual, sin sumarlos ni multiplicarlos. Cuando en estable necesites arrays de tamaño derivado, el recurso habitual es introducir el tamaño como otro parámetro const independiente, o apoyarte en crates como typenum, que codifican los números como tipos.