Rust 1.100 estabiliza `!` tras diez años y cinco intentos fallidos

Rust 1.100 estabiliza `!` tras diez años y cinco intentos fallidos

Tras diez años y cinco intentos fallidos, Rust 1.100 estabiliza el tipo never (`!`), el tipo sin valores que representa cálculos que no terminan normalmente. La versión permite escribirlo en cualquier posición de tipo y convierte `Infallible` en un alias suyo; también modifica la inferencia del tipo never en las ediciones anteriores a 2024.

El equipo de Rust publicó Rust 1.100.0 en el canal estable el 12 de noviembre de 2026. Quienes instalaron una versión anterior con rustup pueden actualizar mediante `rustup update stable`; el equipo también invita a probar versiones futuras con los canales beta o nightly y a informar de los errores encontrados.

`!` deja de estar limitado al retorno

El tipo never, escrito `!`, es el tipo canónico sin valores posibles. Describe cálculos que divergen: no producen un valor y el código que pudiera seguirlos queda inalcanzable. Rust ya asignaba ese tipo a expresiones que interrumpen el flujo, como `return`, `break` y `std::process::exit`.

Antes de esta versión, `!` podía observarse en esos contextos e incluso escribirse como tipo de retorno de una función, pero no podía nombrarse en cualquier lugar. Rust 1.100 elimina esa limitación: ahora puede aparecer, por ejemplo, como tipo de error en `Result`. El equipo presenta ese cambio como la culminación del objetivo del proyecto para estabilizar el tipo.

Rust ya permitía coaccionar `!` a cualquier otro tipo. Como no se puede obtener un valor de tipo never, una rama que diverge puede encajar donde las demás ramas producen un valor. Así, una expresión `match` puede devolver un `u32` en una rama y ejecutar `return` en otra: esta última no aporta un valor, pero su tipo `!` se convierte en el tipo esperado.

La distinción importa porque el tipo never no es simplemente otro tipo vacío. La coerción de `!` a cualquier tipo permite que las expresiones que no continúan la ejecución participen en contextos con un tipo de resultado concreto. La novedad de Rust 1.100 es que ahora el tipo puede nombrarse explícitamente, además de intervenir en esas reglas de control de flujo.

`Infallible` pasa a ser `!`

Rust 1.100 cambia `Infallible` por un alias del tipo never. El tipo `Infallible` se usa para expresar que una operación no puede fallar; al convertirlo en alias, las API existentes que lo emplean pasan a ser compatibles con las que usan `!`. El equipo indica que ese era el plan desde la introducción de `Infallible` y que hacerlo realidad fue uno de los motivos que complicaron la estabilización.

La modificación de `Infallible` trae un cambio de compatibilidad: el fallback del tipo never pasa de `()` a `!` también en las ediciones 2015, 2018 y 2021. En la edición 2024 ese comportamiento ya se había introducido. El cambio puede afectar a código en casos poco frecuentes, como cuando se ignora el resultado de una función que devuelve un parámetro genérico; además, el compilador podría identificar más código como inalcanzable.

El equipo afirma que trató de reducir el impacto con avisos de compatibilidad futura enviados con antelación y con correcciones publicadas para crates públicos afectados. Si una dependencia falla por problemas relacionados con el tipo never, recomienda probar a actualizarla: puede que ya exista una versión corregida.

Rust 1.100 estabiliza `!` tras diez años y cinco intentos fallidos
© The Rust Blog

Un cambio trabajado en varias etapas

La petición de cambios que llevó la estabilización al repositorio fue la pull request #155499, abierta por WaffleLapkin. Según el seguimiento de GitHub, rust-bors integró 18 commits en `rust-lang:main`. La propuesta incluía estabilizar `!`, hacer que `Infallible` fuera un alias y cambiar el fallback del tipo never a `!` en todas las ediciones.

El historial muestra que el proceso tuvo ajustes y revisiones. En abril de 2026 se inició un experimento de Crater, la herramienta que prueba cambios frente a partes del ecosistema Rust. El resultado publicado registró 3.277 regresiones y cero correcciones en un total de 9.024 resultados; el comentario advertía que 1.149 resultados eran espurios en una lista de reintento y sugería repetir la prueba si esa cantidad era significativa.

En agosto, la pull request quedó sin aprobación durante una incidencia relacionada con un rollup y una comprobación de compatibilidad de Cargo. La discusión señaló que `core::convert::Infallible` seguía existiendo, aunque pasaba de ser un `pub enum` a un `pub type`; un participante describió el aviso como un falso positivo de `cargo-semver-checks`. Después, la propuesta volvió a aprobarse y se integró.

El seguimiento de las notas de versión, la incidencia #158197, documentó por separado la estabilización y sus consecuencias de compatibilidad. El borrador para el blog se preparó en septiembre; en él se insistía en que el compilador podría detectar más código inalcanzable. La nota final de Rust 1.100 conserva también la recomendación de actualizar dependencias públicas que hayan recibido correcciones.

Más cambios para Cargo y la biblioteca estándar

El tipo never comparte protagonismo con otras novedades de Rust 1.100. La versión estabiliza partes centrales de la API `Allocator`, con las que autores de bibliotecas pueden definir asignadores personalizados para ciertos tipos de la biblioteca estándar, actualmente `Vec` y `Box`. El equipo la describe como la base del objetivo Allocators 1.0; ampliar la API y su uso en más colecciones y tipos de puntero queda pendiente.

También llega `core::mem::DropGuard`, un tipo auxiliar que ejecuta una clausura al destruirse. Recibe una variable y una clausura, implementa `Deref` y `DerefMut` para permitir seguir usando la variable y consume esa variable cuando se elimina el guard. Su método `dismiss` permite recuperar el valor sin ejecutar el destructor, una opción que sirve para deshacer cambios si una operación falla.

Otra API nueva, `std::mem::conjure_zst`, ofrece una función específica para crear valores de tipos de tamaño cero cuando se sabe que hacerlo es seguro. El equipo la presenta como alternativa a distintas técnicas basadas en transmutaciones o en `MaybeUninit`. La función es `unsafe`: algunos tipos de tamaño cero actúan como marcadores de condiciones necesarias para la seguridad; el blog cita como ejemplo el token `Python

Fuentes: The Rust Blog, GitHub, GitHub, byteiota | From Bits to Bytes