Rust project goal seeks stable tail calls for stack-safe recursion

Stable tail calls could turn recursion-heavy Rust code from a stack-risk into a real technique for interpreters, parsers, decoders, and tight embedded state machines. Folkert de Vries of the Trifecta Tech Foundation has pushed that idea into the Rust project’s 2026 goals process, which is now annual instead of six-monthly.

The timing matters because the goals machinery has gotten more concrete. Niko Matsakis formally kicked off the 2026 process on February 3, 2026, and the goals team said the first draft of the project goals RFC had landed by then. By February 11, the team said there were about 60 proposed goals in play, with January proposals, February feedback, a March RFC, and implementation running from April through December.

This year’s framework also changed shape. Rust replaced the older “flagship themes” language with “Roadmaps” and “Application areas,” and the goals team said those structures are meant to help focus industry funding. That makes tail calls more than a wish list item. It is the kind of proposal that has to survive a roadmap conversation, not just a technical one.

The technical case is straightforward. Proper tail calls let one function hand control to another without growing the call stack, which means tail-recursive loops can act like iteration instead of piling up frames. A 2016 Rust Internals pre-RFC even proposed an explicit `become` keyword for this. That proposal argued tail calls could cut stack usage and make interpreter jump tables faster, which is exactly why the idea keeps resurfacing in low-level Rust discussions.

The caution has been there just as long. In a 2024 Rust Internals discussion, community members pointed out that code depending on tail calls is already non-portable on targets without tail-call optimization. They also argued that Rust users would likely want a lint or an explicit contract, not silent runtime failure, if the compiler could not guarantee the behavior. That is the central tradeoff: performance and stack safety on one side, portability and clear guarantees on the other.

Rust’s own process makes clear that approval is not just about enthusiasm. Every approved project goal needs a named champion and team buy-in, so any stable tail-call effort will need cross-team support and enough capacity to carry it through. The earliest realistic target in the discussion is 2027, which fits the pattern: this is not a quick feature request, but a serious roadmap signal for anyone writing interpreters, parsers, or embedded control loops in Rust.