El tipo never de Rust, representado por el símbolo !, necesitó diez años y cinco intentos fallidos de estabilización antes de llegar a estable. Rust 1.100.0, publicado el 12 de noviembre de 2026, por fin lo logra y de paso completa uno de los objetivos de proyecto que el equipo arrastraba desde hace años (Rust Blog).
Qué es el tipo never de Rust y por qué existe
El tipo never es el tipo canónico sin habitantes de Rust: no existe ningún valor posible de ese tipo, porque representa un cómputo que nunca llega a resolverse en un valor (documentación de std, Rust Blog). Expresiones como return, break o std::process::exit tienen ese tipo, igual que un bucle sin salida. Como es imposible tener un valor de never, el compilador permite convertirlo a cualquier otro tipo: así una rama de un match que hace return puede convivir con otra que devuelve un u32, sin romper el chequeo de tipos.
Hasta la versión anterior, never ya se podía usar y observar de esta forma, incluso como tipo de retorno explícito, pero no se podía nombrar en cualquier posición genérica. Rust 1.100.0 permite escribirlo donde haga falta, por ejemplo en Result<T, !> para una función que jamás puede fallar, algo que antes de esta versión no compilaba (Rust Blog).
El problema real: diez años tratando de no romper nada
Lo que retrasó la estabilización no fue el tipo en sí, sino una pieza colateral: std::convert::Infallible, el tipo que la librería estándar usaba desde hace años para marcar que una operación no puede fallar. Rust 1.100.0 convierte Infallible en un alias de never, para que todo el código que ya usaba Infallible sea compatible de forma automática con el never type nativo (Rust Blog).
Para lograrlo sin romper buena parte del ecosistema, el equipo tuvo que cambiar el llamado never type fallback: en las ediciones 2015, 2018 y 2021, una expresión de tipo never que no se usaba se inferiría como (); ahora se infiere como never, igual que ya pasaba en la edición 2024 (Rust Blog). El propio anuncio reconoce que este cambio puede hacer que el compilador detecte más código como inalcanzable de lo que detectaba antes, y que uno de los ingenieros del compilador, conocido como waffle, dio una charla completa sobre las dificultades concretas de esta estabilización.
Cinco intentos de estabilización fallaron antes de este, según el anuncio oficial.
Qué significa para vos si mantenés un crate en Rust
Si mantenés una librería que expone Result<T, Infallible>, algo común en parsers, conversiones TryFrom o builders, no tenés que tocar nada: el alias es retrocompatible. Pero si tu CI compila con #![deny(warnings)] sobre una edición 2015, 2018 o 2021, conviene correr un build apenas actualices el toolchain. El cambio en el fallback puede hacer que el compilador marque como código muerto ramas que antes pasaban silenciosamente, porque ahora infiere never donde antes inferia () (Rust Blog).
El equipo de Rust avisó este cambio con advertencias de compatibilidad futura con bastante anticipación y ya salieron parches para los crates públicos que se rompían con el nuevo comportamiento, según el anuncio. Si una dependencia falla justo después de actualizar a 1.100.0, lo primero que conviene revisar es si ya existe una versión más nueva de esa dependencia antes de buscar el error en tu propio código.
El never type no es una idea exclusiva de Rust
La idea de un tipo sin habitantes que se puede convertir a cualquier otro no nació con Rust. Varios lenguajes con sistemas de tipos fuertes tienen su propia versión, con matices distintos en cómo coacciona y dónde se usa:
LenguajeTipo equivalenteCoacción automáticaUso típicoRustnever (!)Sí, a cualquier tiporeturn, break, process::exit, ResultTypeScriptneverNo hay coacción implícita; el compilador lo usa para chequeos de exhaustividadFunciones que nunca retornan, uniones discriminadasHaskellVoidSí, mediante la función absurdTipos de error que el programa declara imposiblesKotlinNothingSí, subtipo de todos los tiposFunciones que siempre lanzan excepción, TODO()
En el hilo de Hacker News sobre el lanzamiento, un comentario conecta esta clase de garantías con el valor general del sistema de tipos de Rust: según el usuario IshKebab, un sistema de tipos fuerte "ayuda a atrapar bugs en tiempo de compilación" y permite el patrón type state para "hacer que los estados inválidos sean irrepresentables" (comentario en Hacker News). El never type es, en ese sentido, la versión más extrema de esa misma idea: un estado que el propio tipo declara imposible de habitar, en vez de dejarlo como un caso que el programa debe chequear en tiempo de ejecución.
Lo que trae de paso: Allocator API y límites en Cargo
El never type no viaja solo en esta versión. Rust 1.100.0 también estabiliza el núcleo de la Allocator API (trait Allocator en std, Rust Blog): por ahora solo Vec y Box pueden usar un asignador de memoria personalizado a través de ese trait, con más colecciones y tipos de puntero prometidos para versiones futuras.
También llega core::mem::DropGuard, un tipo que ejecuta un closure al salir de alcance sin tener que implementar Drop a mano, con un método dismiss que permite construir operaciones de todo o nada con rollback, por ejemplo en un parser que debe dejar un Vec intacto si falla a mitad de camino. Y para publicar en crates.io, Cargo suma min-publish-age, una antigüedad mínima exigida antes de permitir publicar una versión, pensada para frenar ataques de cadena de suministro que dependen de paquetes recién creados, además de reportar dependencias sin usar y reducir colisiones de caché (Rust Blog).
Limitaciones y cuándo te puede doler
La Allocator API estabilizada cubre solo el trait y dos colecciones. Si necesitás asignadores personalizados en HashMap, BTreeMap o Rc, todavía no están soportados y hay que esperar nuevas estabilizaciones (Rust Blog).
El cambio de fallback del never type es, por diseño, casi imperceptible, pero el propio anuncio advierte que puede afectar código en casos raros, por ejemplo cuando se ignora el resultado de una función genérica. Si tu build falla justo después de actualizar y el error menciona inferencia de tipos o código inalcanzable, ese cambio es el primer sospechoso, no un bug nuevo del compilador.
Referencias
- Announcing Rust 1.100.0 (Rust Blog): anuncio oficial de la estabilización del never type, el alias de Infallible, el cambio de fallback, la Allocator API, DropGuard y Cargo min-publish-age.- Documentación del tipo never en std: referencia oficial del tipo never y la coacción never-to-any.- Trait Allocator en std: referencia oficial de la Allocator API estabilizada en esta versión.- Rust 1.100 (Hacker News): hilo de discusión de la comunidad sobre el lanzamiento.- Comentario de IshKebab en Hacker News: argumento sobre por qué un sistema de tipos fuerte como el de Rust ayuda a prevenir bugs y a representar estados inválidos como irrepresentables.
Seguimos el tema en @programacion.
