Rust 1.21 lets constant references outlive a local binding
Static promotion gives suitable constant expressions static storage without a named static item. The change preserves borrowing requirements while removing an unnecessary local-lifetime restriction.
A reference to the literal integer five need not borrow storage owned by the current stack frame. The value is fixed, and the compiler can place it in static storage. Rust 1.21 makes that possibility part of the lifetime behavior visible to the program, so a suitable constant expression can supply a static reference without a separate named item.
The October 12 announcement illustrates the change with a reference moved into a spawned thread. The earlier compiler rejected it because the temporary had a local lifetime. RFC 1414 explains the more general motivation, including the verbosity of naming constants solely to obtain references with static lifetimes.
I value the borrowing rules because they make the validity of a reference part of the program contract. This change keeps that requirement while recognizing storage that does not need to expire with a local frame. The shorter code is useful because the compiler can justify it, not because it has stopped checking the lifetime.
The reference and the binding have different lifetimes
The announcement compares a local literal reference with an explicitly named static integer. When the compiler promotes the referenced expression, the storage has a static lifetime even though a local variable holds the reference. The lifetime of that variable does not determine when the referenced integer disappears.
This distinction can be demonstrated without a thread or an execution-order concern. A function can return the reference to its caller when the value qualifies for promotion.
fn default_limit() -> &'static u32 {
&42
}
The value forty-two is example data. This function does not return a pointer to an ordinary local variable whose storage has expired. The compiler gives the constant expression a suitable static location, so the return type can state the longer lifetime.
The RFC describes the earlier workaround of declaring a static item inside the function and returning its reference. Promotion removes the need for that otherwise unused item name. The programmer can state the value directly where it is needed.
Promotion requires a suitable expression
The rule is not a general lifetime extension for arbitrary local data. The RFC concerns shared references to constant expressions that satisfy restrictions, including restrictions involving UnsafeCell. Those conditions preserve the immutability required for the promoted value behind a shared reference.
An expression whose value depends on ordinary runtime input cannot be assumed to have the same behavior as a literal in static storage. Similarly, interior mutability raises questions that a fixed integer does not. The compiler still distinguishes which expressions qualify instead of promoting every borrow that would otherwise fail.
This is important when explaining the thread example. Moving a reference into a closure does not make its referent live longer by itself. The successful case works because the compiler can provide static storage for the referenced constant. Moving a reference to an unrelated local object would not establish that condition.
The RFC also explains why the mechanism is more general than a local spelling convenience. A named constant item inside a generic function cannot simply use the enclosing type parameters as if it were an ordinary local expression. Promotion can handle useful constant-expression patterns without introducing that separate item boundary.
The feature therefore combines reduced annotation with a specific storage decision. A reader still needs to distinguish an owned value, a borrow of runtime data, and a reference to promoted constant data. The new rule removes one unnecessary restriction among those cases rather than merging their ownership behavior.
Documentation needs to match the toolchain
Rust 1.21 also addresses a different kind of mismatch between what a user reads and what the compiler accepts. Cargo documentation has historically updated outside the language release train. The announcement says users could read about a nightly feature for up to twelve weeks before it reached their version.
The proposed new documentation location is doc.rust-lang.org/cargo. As of this announcement, it still redirects to the existing site, with the versioned move described as future release work. The useful current fact is the transition plan and its reason, not a claim that the entire migration is already complete.
The release also introduces an initial rustdoc book and broadens the hosted standard-library operating-system documentation beyond the Linux platform used to build it. The latter is specifically a standard-library facility at this point. These changes reduce gaps in the material a developer consults while reasoning about platform behavior.
I see accurate version context as part of a usable systems language. A correct explanation of a feature is still misleading when it silently describes a toolchain the reader does not have. The announcement identifies that problem directly for Cargo, while the promotion example shows why the difference between compiler versions can affect whether the same source is accepted.
The library also gains Iterator::for_each for consuming an iterator through a side-effecting closure. The announcement presents it as an alternative whose usefulness depends on the surrounding iterator chain. A straightforward loop remains readable in simple cases. The release gives programmers another standard expression for an existing operation while its lifetime change accepts constant references that previously needed an explicit static item.