El tipo never de Rust, explicado

El tipo never de Rust es el tipo de una expresión que nunca produce un valor. Se escribe con un solo signo de exclamación, !. Una función que siempre entra en pánico, se repite sin fin o sale pronto tiene este tipo, porque nunca devuelve un valor al código que la sigue. Tras diez años como característica inestable, el tipo never ya es estable. La pull request que lo hizo se fusionó el 24 de agosto de 2026, y trae consigo un cambio incompatible.

Esto importa más allá de una curiosidad del compilador. El tipo never decide qué ocurre en los callejones sin salida de su código, y la nueva regla de respaldo puede cambiar lo que infiere una función genérica. La Rust Reference define ! como un tipo sin valores, que representa cómputos que nunca terminan.

Cómo funciona

Un tipo es un conjunto de valores posibles. El tipo bool tiene dos. El tipo never no tiene ninguno. La RFC 1216, la propuesta de 2015 que empezó todo esto, llama a un tipo así un tipo vacío, «un tipo para el que no existe nada de ese tipo». Nada de tipo ! puede existir mientras un programa se ejecuta, así que un valor de ese tipo no tiene ninguna representación a nivel de máquina.

Ese vacío le da a ! su único poder especial. Según la documentación de la biblioteca estándar de Rust, una expresión de tipo ! puede convertirse por coerción en cualquier otro tipo. El compilador puede prometerlo con seguridad, porque la coerción nunca tiene que ejecutarse. Si el código que sigue a un panic!() espera un String, la expresión de pánico encaja, ya que allí nunca hará falta ningún String. Por eso return, break, continue y panic!() pueden estar todos en una posición que espera algún otro tipo.

La biblioteca estándar documenta que ! implementa Clone, Copy, Debug, Display, Eq, Hash, Ord, PartialEq, PartialOrd y Error. La misma documentación nombra un trait que nunca debería implementar: Default. Default tiene que producir un valor, y ! no puede.

Antes de esta estabilización, Rust estable le dejaba escribir ! en un solo lugar, como tipo de retorno de una función, según la Reference. Los desarrolladores que necesitaban un tipo vacío en otro sitio escribían el suyo, normalmente enum Never {}, un patrón que la RFC 1216 describe. La versión propia de la biblioteca estándar es std::convert::Infallible, un enum sin variantes que está en la biblioteca desde Rust 1.34.0. Su documentación lo describe como el tipo de error para errores que nunca pueden ocurrir. Un Result<T, Infallible> le dice al lector que el resultado siempre es Ok.

Qué cambió y cuándo

Tres cosas llegaron juntas en la pull request 155499, según la PR. Primero, ! es estable como tipo completo, que es lo que la RFC 1216 pidió en 2015. Segundo, Infallible pasa a ser un alias de tipo de !, así que los dos nombres significan ahora el mismo tipo. Tercero, y esta es la parte que rompe, el respaldo de tipos ahora se resuelve a ! en toda edición de Rust.

El respaldo es la regla para un caso límite. A veces el compilador llega a un punto donde una expresión diverge y nada a su alrededor fija un tipo. Históricamente elegía allí el tipo unit (), la tupla vacía. En la edición 2024 y posteriores, la documentación de la biblioteca estándar ya describe el respaldo como ! en su lugar. La PR de estabilización convierte eso en la regla en todas partes, incluidas las ediciones anteriores.

El proyecto Rust midió el cambio antes de fusionarlo. La PR informa de una ejecución de crater sobre 9.024 crates. crater compila una muestra amplia de las crates publicadas contra un compilador propuesto e informa de lo que se rompe. Marcó 3.277 regresiones y ninguna corrección. La PR está prevista para Rust 1.100.0, como señaló el artículo de Tech AI Wire sobre la estabilización cuando se fusionó.

Un informe de regresión es instructivo. Un colaborador señaló que cargo-semver-checks, una herramienta que revisa las crates en busca de cambios incompatibles de API, reportaba el cambio de Infallible como incompatible. La discusión de la PR lo califica de falso positivo. Como lo expresó el colaborador JonathanBrouwer, «El tipo sigue ahí, solo pasó de un pub enum a un pub type.»

Hito	Cuándo	Qué ocurrió
RFC 1216	19 de julio de 2015	Propuso promover ! a tipo completo
Ticket de seguimiento 35121	29 de julio de 2016	Abierto para seguir la RFC; la PR 35162 fue la primera implementación
PR 65355	Rust 1.41.0	Primera estabilización, revertida en la PR 67224 tras regresiones
Edición Rust 2024	Edición 2024	Respaldo cambiado a ! primero dentro de la nueva edición
PR 155499	24 de agosto de 2026	! estable, respaldo universal, Infallible convertido en alias

Por qué llevó diez años

El ticket de seguimiento cuenta la historia del retraso. El ticket 35121 se abrió el 29 de julio de 2016. Una primera estabilización se publicó en Rust 1.41.0 y luego se retiró, porque crates reales se rompieron. El ticket registra el detonante: una conversión de Error desde Infallible dejó de compilar, reportada como el ticket 66757. El autor de la PR final escribe en su blog que hubo cinco intentos fallidos en total. Este último empujón le llevó más de dos años.

La salida fue hacerlo por fases. El ticket de seguimiento expone un plan en tres fases. Cambiar el respaldo a ! solo dentro de la edición 2024. Estabilizar esa edición. Después, una vez que el ecosistema hubiera absorbido la nueva regla, hacer universales los cambios incompatibles y fijar Infallible igual a !. La PR de agosto de 2026 es esa fase final. El otro gran cambio del compilador de Rust este año, el solucionador de traits de nueva generación, pasa primero por nightly con la misma cautela, con la estabilización prevista para más adelante.

Qué significa esto para los desarrolladores

Revise el código genérico en nightly antes de que Rust 1.100.0 llegue a estable. El cambio de respaldo importa donde un parámetro de tipo solo queda fijado por una expresión que entra en pánico o sale pronto. En esos puntos el compilador solía elegir () por usted y ahora elige !. La mayor parte del código no lo notará. El código que dependía de la elección antigua puede fallar al compilar, o elegir una implementación de trait distinta. Los 3.277 casos detectados por crater muestran que no es hipotético.

Busque Infallible con grep. Si su crate implementa un trait tanto para Infallible como para !, esas dos implementaciones ahora chocan, porque nombran un solo tipo. La documentación de Infallible también señala que tipos de puntero a función como fn() -> ! y fn() -> Infallible podían llevar implementaciones de trait distintas. Esos ahora también coinciden. Una biblioteca que expone Infallible en su API pública no rompe a sus usuarios, diga lo que diga una herramienta de semver. El tipo sigue ahí bajo los dos nombres.

Use ! a propósito de ahora en adelante. Una función que solo puede tener éxito puede devolver Result<T, !>, que la RFC 1216 lista como caso de uso motivador, y quienes la llaman pueden hacer match solo sobre el brazo Ok. Un manejador que nunca retorna puede pasarse a código genérico que espera un Fn() -> T, otro caso de uso de la RFC, sin un tipo envoltorio. Abandone el enum Never {} casero en cuanto su versión mínima de Rust admitida lo permita.

Diez años es mucho tiempo para un tipo de un solo carácter. El primer intento revertido, el despliegue que pasó primero por una edición y la cifra de crater explican la mayor parte. También son la razón de que este sea un cambio para el que puede prepararse hoy en nightly, antes de que llegue a estable.