Rust stabilizes the never type after ten years and five attempts

Rust's never type is finally stable. The pull request that did it, numbered 155499, merged into rust-lang/rust on 24 August 2026 and is milestoned for Rust 1.100.0. It carries a breaking change with it, so this is a release note to read rather than skim.

The never type is written as a single exclamation mark. It is the type of an expression that never produces a value, because it panics, loops forever, or returns out of the function first. Rust has used it internally for years to type those dead ends. What was missing was the ability for your own code to write it down and rely on it.

What actually changed

Three things ship together, according to the pull request.

• The never type is stable, and the PR closes the tracking issues numbered 35121 and 148922.
• Every Rust edition now resolves an unconstrained never type to the never type, instead of falling back to the empty tuple. This is the breaking part.
• The standard library's std::convert::Infallible becomes a plain type alias for the never type.

The fallback change needs unpacking, because it is the one that can alter what your code does. Sometimes the compiler reaches a spot where a value can never exist and no type has been pinned down. Historically it picked the empty tuple there, written as a pair of parentheses. Now it picks the never type. Since the old fallback no longer happens, the PR also removes the warning that existed to flag code depending on it, named dependency_on_unit_never_type_fallback.

That is a real behavior change and the Rust project measured it. The PR reports that crater, the tool that compiles a large slice of published crates against a proposed compiler, initially surfaced 3,277 regressions. The final change landed in 18 commits of fixes, tests, and documentation.

Ten years of trying

The tracking issue tells the longer story. Issue 35121 was opened on 29 July 2016 to track RFC 1216, the proposal to promote the exclamation mark from special notation to a real type. That is ten years open. The author of this week's PR writes on their blog that there were five earlier stabilization attempts, and that this effort alone took more than two years.

Milestone recorded in the tracking issue	What happened
RFC 1216, issue 35121 opened July 2016	Promote the never type to a real type
PR 35162	First implementation
PR 65355	Stabilization aimed at Rust 1.41.0
PR 67224	That stabilization reverted after regressions
Issue 123748	Fallback changed inside the Rust 2024 edition first
PR 155499, merged August 2026	Fallback made universal, never type stabilized

The revert is the instructive entry. Stabilization was attempted, real crates broke, and the change was pulled back out. The recorded blockers on the issue are all regression reports, numbered 66757, 67225, and 65992, the last covering how expressions that diverge should fall back. The eventual route around the problem was to change the fallback in one edition first, then make it universal once the ecosystem had absorbed it.

What this means for developers

Do not wait for 1.100.0 to find out. Build your crate on nightly now and read the diagnostics, because fallback changes are the class of breakage that compiles quietly in one place and fails in another. Pay attention to generic code where a type parameter is only pinned down by an expression that panics or returns early. That is exactly where the compiler used to choose the empty tuple for you.

The Infallible change is the one to grep for. If your error types use std::convert::Infallible, it is now an alias rather than its own enum. Aliases behave differently in two specific places. You can no longer write a distinct trait implementation for it separately from the never type, and any match arm that constructs it needs a second look. Most code will be unaffected, but a library that implements conversions over both names should check for a conflict before 1.100.0 reaches stable.

There is also a cleanup worth doing. If you silenced or worked around the dependency_on_unit_never_type_fallback warning, those workarounds are now dead weight and the lint that justified them is gone. Search for it, remove the scaffolding, and let the type checker do the work instead.

The wider lesson is about how Rust ships breaking changes at all. The pattern here is worth copying if you maintain a library with real users. Gate the new behavior behind an opt-in boundary, which in Rust's case is an edition. Measure the blast radius against actual published code. Then make it universal only once that number comes down. Ten years looks slow from outside. A reverted stabilization and a crater run flagging 3,277 crates explain most of it.