Rust's November goals report distinguishes approval from delivery

Async closure stabilization has been approved, but the stabilization change has not yet landed. That is the first distinction in Rust's November project-goals update, published on December 16. It is also a useful way to read the whole report. A decision, an implementation merge, and a stable user-facing capability are different milestones.

The report follows the August selection of 26 project goals. That process assigned owners and recorded team support, while explicitly allowing that some goals would remain unfinished. December's account includes progress, blocked work, and an effort being closed for lack of steady progress.

I value Rust's suitability for systems work, and these details are more useful than treating its roadmap as a collection of promised features. They expose the technical and organizational steps between an agreed direction and something a project can depend on.

Async closures retain a named-trait design

For async closures, the language team chose the trait name AsyncFn instead of the originally proposed keyword-based async Fn syntax. The update explains that broader discussion had not established consensus about applying an async Trait keyword form generally. A named trait provided an acceptable next step without settling that broader syntax question.

The report says a future general syntax could allow AsyncFn to become an alias. That is an explanation of how the current decision might fit a broader design, not an announcement that the broader design has been adopted. The immediate status remains approved stabilization awaiting its landing.

Return-type notation has a separate status. The update records an extension covering Self::foo(..): Send and a compiler-crash fix, leaving its stabilization pull request unblocked. Unblocking a proposal is progress because another step can proceed. It does not mean every intended use has reached stable Rust.

Other parts of the async effort had no major progress, including async-drop reviews and team reorganization. Recording those alongside successful changes gives a more accurate picture of the flagship goal than highlighting only the feature nearest completion.

Linux requirements produce specific compiler changes

The Linux flagship update records the rename from derive(SmartPointer) to derive(CoercePointee), followed by work to update the Rust-for-Linux codebase. This is a concrete integration consequence. A compiler-facing change needs corresponding adoption by the project that depends on it.

The report also describes an RFC on compiler flags that alter the ABI. That work concerns how to manage configurations affecting interfaces between compiled components. It belongs to the Linux goal because a stable toolchain must support the actual requirements of the integration, not merely compile an isolated language example.

Another merged change makes target blocks in asm-goto safe by default. The update states that this decision follows experience from Rust for Linux. It separately identifies an extension involving embedded pointers as still being finalized. The report therefore distinguishes a decision supported by integration experience from adjacent work still underway.

Reference documentation is part of that work too. The update notes a prepared documentation change for pointers to statics in constants, a capability stabilized the previous month. Implementation and documentation can have different progress markers even when they describe the same language feature.

Manifest changes can break downstream crates

The cargo-semver-checks goal has a particularly practical update. Manifest linting has merged, extending detection beyond source-code changes. Removing a package feature is the example. A dependent crate that still requests the removed feature no longer builds even if the library's Rust item declarations are unchanged.

This makes the package manifest part of the compatibility contract. A source-level API comparison alone cannot identify every change that affects dependency selection and compilation. The checker needs information about how consumers configure the package as well as the types they import.

The report also records work on type information in lints and agreements needed for cross-crate checking. Those are supporting mechanisms, not evidence that merging the tool into Cargo has already happened. The goal's title concerns resolving blockers toward that larger integration.

I find the manifest example useful because it states the failure in a form a library maintainer can recognize. Removing a feature breaks a consumer's existing request. The compatibility issue exists before any function call or trait obligation is checked.

An experiment can finish without becoming a product feature

The sandboxed-build-script exploration is complete. The report says continuation is unlikely and identifies research that may inform other efforts. That is a completed exploration with a limited outcome, rather than a claim that Cargo now executes build scripts in a new stable sandbox.

The update also closes the a-mir-formality testing-infrastructure goal because progress has not been steady. This matches the original planning process's acknowledgment that volunteer work can stall and may need reconsideration. Closing the goal makes its status explicit instead of leaving acceptance to imply continuing delivery.

Rust 2024 preparation, meanwhile, has reached a call-for-testing stage described in the report. That is a request for feedback on an upcoming edition. It should be distinguished from a stable edition announcement, just as approval of async closure stabilization should be distinguished from its landing.

The report supplies concrete evidence of movement through those stages. Some changes have merged, some decisions unblock the next step, and some investigations have ended. Reading those statuses literally gives contributors and users a better basis for choosing what to test, what to help implement, and what is still unavailable as a stable dependency.