Rust estabiliza el tipo never tras diez años y cinco intentos

El tipo never de Rust ya es estable. La pull request que lo hizo, con el número 155499, se fusionó en rust-lang/rust el 24 de agosto de 2026 y está prevista para Rust 1.100.0. Trae consigo un cambio incompatible. Es, por tanto, una nota de versión para leer y no para ojear.

El tipo never se escribe con un solo signo de exclamación. Es el tipo de una expresión que nunca produce un valor, porque entra en pánico, se repite sin fin, o sale antes de la función. Rust lo ha usado internamente durante años para tipar esos callejones sin salida. Lo que faltaba era poder escribirlo en el código propio y confiar en él.

Qué cambió en realidad

Según la pull request, llegan tres cosas juntas.

• El tipo never es estable, y la PR cierra los tickets de seguimiento con los números 35121 y 148922.
• Toda edición de Rust resuelve ahora un tipo never sin restringir hacia el tipo never, en lugar de recaer en la tupla vacía. Esta es la parte que rompe.
• El std::convert::Infallible de la biblioteca estándar pasa a ser un simple alias de tipo del tipo never.

El cambio de respaldo hay que desplegarlo, porque es el que puede alterar lo que hace su código. A veces el compilador llega a un punto donde un valor nunca puede existir y no se ha fijado ningún tipo. Históricamente allí elegía la tupla vacía, escrita como un par de paréntesis. Ahora elige el tipo never. Como el respaldo antiguo ya no ocurre, la PR también elimina el aviso que marcaba el código que dependía de él, llamado dependency_on_unit_never_type_fallback.

Es un cambio de comportamiento real, y el proyecto Rust lo midió. La PR informa que crater arrojó al principio 3.277 regresiones. crater es la herramienta que compila una porción amplia de las crates publicadas contra un compilador propuesto. El cambio final quedó en 18 commits de correcciones, pruebas y documentación.

Diez años de intentos

El ticket de seguimiento cuenta la historia larga. El ticket 35121 se abrió el 29 de julio de 2016 para seguir la RFC 1216, la propuesta de promover el signo de exclamación de notación especial a tipo real. Son diez años abierto. El autor de la PR de esta semana escribe en su blog que hubo cinco intentos previos de estabilización, y que solo este esfuerzo llevó más de dos años.

Hito registrado en el ticket de seguimiento	Qué ocurrió
RFC 1216, ticket 35121 abierto en julio de 2016	Promover el tipo never a tipo real
PR 35162	Primera implementación
PR 65355	Estabilización dirigida a Rust 1.41.0
PR 67224	Esa estabilización revertida tras regresiones
Ticket 123748	Respaldo cambiado primero dentro de la edición Rust 2024
PR 155499, fusionada en agosto de 2026	Respaldo hecho universal, tipo never estabilizado

La reversión es la entrada instructiva. Se intentó la estabilización, crates reales se rompieron, y el cambio se volvió a sacar. Los bloqueos registrados en el ticket son todos informes de regresión, con los números 66757, 67225 y 65992. El último trata de cómo deben recaer las expresiones que divergen. La ruta para rodear el problema fue cambiar el respaldo primero en una edición, y hacerlo universal una vez que el ecosistema lo había absorbido.

Qué significa esto para los desarrolladores

No espere a 1.100.0 para averiguarlo. Compile su crate en nightly ahora y lea los diagnósticos. Los cambios de respaldo son la clase de rotura que compila en silencio en un sitio y falla en otro. Preste atención al código genérico donde un parámetro de tipo solo queda fijado por una expresión que entra en pánico o sale pronto. Ahí es exactamente donde el compilador solía elegir la tupla vacía por usted.

El cambio de Infallible es el que hay que buscar con grep. Si sus tipos de error usan std::convert::Infallible, ahora es un alias y no su propio enum. Los alias se comportan distinto en dos lugares concretos. Ya no puede escribir una implementación de trait propia para él, separada del tipo never, y cualquier brazo de match que lo construya merece una segunda mirada. La mayor parte del código no se verá afectada. Pero una biblioteca que implemente conversiones sobre los dos nombres debería comprobar si hay conflicto antes de que 1.100.0 llegue a estable.

Hay además una limpieza que vale la pena. Si silenció o rodeó el aviso dependency_on_unit_never_type_fallback, esos rodeos son ahora peso muerto, y el lint que los justificaba ya no está. Búsquelo, quite el andamiaje y deje que el verificador de tipos haga el trabajo.

La lección más amplia trata de cómo entrega Rust los cambios incompatibles. El patrón merece copiarse si mantiene una biblioteca con usuarios reales. Ponga el comportamiento nuevo detrás de una frontera de adhesión voluntaria, que en el caso de Rust es una edición. Mida el radio de impacto contra código realmente publicado. Y hágalo universal solo cuando ese número baje. Diez años parecen lentos desde fuera. Una estabilización revertida y una ejecución de crater que marcó 3.277 crates explican la mayor parte.