Rust 1.88 brings let chains to the 2024 edition

Nested pattern matches often express one decision through several levels of indentation. Flattening them is not always a matter of matching a tuple, because a later operation may depend on a value bound by an earlier match. It may also be incorrect to evaluate that later operation when the earlier condition fails. Rust's let chains preserve those dependencies in one short-circuiting condition.

Rust 1.88, released on June 26, stabilizes let chains for the 2024 edition. The restriction is deliberate. The release explanation connects the feature to the edition's revised temporary scopes, which made the implementation's drop behavior tractable after earlier attempts across all editions encountered difficult edge cases.

I like changes that reduce incidental nesting while keeping execution order visible. Rust's appeal for me is its combination of expressiveness and precise semantics. Let chains are useful when their order describes the operation directly, without needing a local macro or an artificial helper function to hide the nesting.

Later matches can use earlier bindings

RFC 2497 describes the original motivation. A condition can combine pattern matches and boolean expressions with &&. Bindings established by an earlier match are available to later parts and to the successful body. A failure stops evaluation of the remaining chain.

fn positive_limit(text: Option<&str>) -> Option<u32> {
    if let Some(text) = text
        && let Ok(limit) = text.parse::<u32>()
        && limit > 0
    {
        Some(limit)
    } else {
        None
    }
}

This example requires Rust 1.88 and edition 2024. Parsing only occurs after the optional input has supplied text. The final comparison only occurs after parsing has supplied a number. The function's single fallback intentionally treats absent input, invalid input, and zero as the same application result.

That last policy is part of the example, not a rule that every parser should follow. An API that needs to distinguish missing configuration from invalid configuration should keep those outcomes separate. Flattening control flow should not erase information the caller requires.

Matching a tuple of results would not generally preserve the same execution. Constructing a tuple evaluates its component expressions, while the chain short-circuits. It also cannot directly express a second call that needs a binding created by the first tuple component. The chain's usefulness follows from those semantics, not simply its number of braces.

A chain does not make let a general boolean value

The stabilized feature applies in if and while conditions. It combines matching with boolean tests in those control-flow positions. It should not be read as introducing an ordinary boolean-valued assignment expression that can appear wherever a boolean is accepted.

That boundary helps explain scope. A binding exists where earlier successful matches establish it. A short-circuiting conjunction has a clear successful path on which all required bindings are present. Extending the same syntax to arbitrary boolean combinations would raise additional questions about which branch established each name.

The RFC discusses several alternatives, including labeled blocks and local macros. Those mechanisms can remove nesting but make the reader understand another local control-flow convention. A supported language form supplies shared syntax for the common case while keeping each dependency in the condition itself.

There is still a readability limit. A long chain that mixes unrelated checks can be harder to understand than a small function with separate branches. The natural unit is a dependent decision. Conditions with different recovery behavior or distinct error reporting may deserve separate code even when the syntax can combine them.

Temporary lifetime changes make the edition relevant

The edition guide's temporary-scope chapter explains a concrete problem with older if let behavior. A temporary lock guard created while evaluating the matched expression could remain alive through the else branch. Attempting an incompatible lock acquisition there could deadlock.

Rust 2024 drops these temporaries before entering else, or after the successful branch completes. This gives the unsuccessful path a different resource lifetime. A guard is an owned value whose destruction releases a resource, so changing its scope changes synchronization behavior as well as the lifetime of an invisible compiler temporary.

Edition migration tooling can conservatively rewrite an if let into a match to preserve earlier temporary behavior. That preserves semantics, but it is not necessarily the behavior an application wants. The guide specifically asks maintainers to review those conversions. A migration tool cannot infer whether an extended lock lifetime is an intended invariant or a bug.

The release therefore ties let-chain availability to an established semantic boundary. Updating a compiler while keeping an older edition does not activate every new interpretation. A project choosing the 2024 edition gains the temporary rules on which the new chain implementation depends.

Naked functions assign the whole body to assembly

Rust 1.88 also stabilizes naked functions. The release specifies #[unsafe(naked)] with a body consisting of one naked_asm! invocation. The compiler does not generate an ordinary function prologue or epilogue, so the assembly author controls the complete body.

This is useful at low-level boundaries where compiler-generated setup would interfere with the required entry sequence. It is also a substantial responsibility. A Rust signature describes the calling interface, but the compiler does not insert ordinary argument handling around the assembly. The body must implement the declared convention and return behavior itself.

The release describes the feature as an alternative to defining whole functions through global_asm!. A Rust declaration can retain a visible signature around the implementation. That improves the connection between the interface and the handwritten body, without making an arbitrary assembly sequence valid merely because it has a typed declaration.

I consider this an appropriate separation for a systems language. Most code should keep the compiler's ordinary function handling. Code that replaces that handling needs a distinct form that makes the change explicit. The unsafe attribute identifies an implementation obligation even when the resulting function could have a safe calling contract.

Configuration gains direct boolean literals

RFC 3695 explains the smaller addition of true and false to configuration predicates. Before this release, empty all() and any() lists could express unconditional inclusion and exclusion. Those forms required remembering the identity values of the logical operations.

The new literals apply in conditional-compilation attributes and the cfg! macro, with corresponding support in Cargo target predicates. The benefit is an explicit spelling of an already expressible condition. It does not make permanently disabled source a useful maintenance strategy or replace meaningful feature selection.

For generated code and temporary development changes, the literal also avoids inventing a fake configuration identifier. A condition that is always false states exactly that, instead of relying on an option that the current build happens not to define. This keeps the intended predicate distinct from the surrounding build environment.

Cargo starts retiring unused cache entries

The release activates automatic cache cleaning after earlier Cargo versions began tracking access. Network-downloaded files become eligible after three months without access, while locally obtained files use a one-month threshold. Offline and frozen operations do not perform that automatic cleanup.

The earlier cache-cleaning design announcement explains why tracking preceded deletion. Different installed Cargo versions share a cache, so cleanup needs evidence about which entries remain in use. Introducing access tracking first reduces the chance that a later cleaner immediately discards everything older commands still need.

The 1.88 announcement identifies Cargo 1.78 as the start of that tracking and documents an opt-out for users who still regularly use older versions. This is a maintenance detail with an operational consequence. A shared cache's apparent inactivity depends on which tools can record access, not merely on whether a developer has used the dependency recently.

The standard library also adds slice::as_chunks, which returns a slice of fixed-size arrays and a remainder. Array size is a const generic parameter, so consumers of the complete chunks receive that size in the type. A remainder preserves any elements that do not form a complete chunk. A zero chunk size panics, as the documentation states. This is another case where one operation establishes a structural condition before returning a more specific view to its caller, avoiding a repeated conversion for every complete group.

Rust 1.88 consequently changes several boundaries with explicit contracts. Let chains preserve dependent evaluation under the 2024 scope rules. Naked functions transfer complete body generation to assembly, and cache cleaning uses tracked access to determine retirement. Each mechanism becomes useful when the code or tooling states the condition on which its behavior depends.