Rust all-hands recap explains the work behind the 2018 edition

Rust needs a way to improve the experience of writing systems software without making existing applications obsolete. The all-hands recap published by Aaron Turon on April 6, 2018 describes the coordination behind that effort. The Berlin meeting itself took place in March 2018. More than 50 participants, mostly volunteers, represented 15 teams or working groups. The April publication reports their plans for the 2018 edition and the formation of verification and codegen working groups.

The recap explicitly preserves the public decision process. Agreement in Berlin does not finalize a language change, and major decisions still require RFCs. That distinction matters when reading its descriptions of stabilization work. A meeting can identify an approach and allocate effort while leaving the resulting proposal open to review.

I find Rust compelling for work that might otherwise call for C. Its semantics make the language interesting, but the effort needed to adopt those semantics matters too. Edition planning addresses that practical question without requiring enthusiasm for every proposed feature.

Compatibility is part of the edition design

The March 12 roadmap sets productivity as the theme for Rust 2018. The normal six-week compiler release schedule continues. An edition groups improvements into a documented experience, with tooling and libraries that fit the language changes.

The proposed Cargo setting makes the choice explicit for each crate. This is the planned opt-in shown in the roadmap, not an instruction to assume edition support in every current stable toolchain.

edition = "2018"

Crates using different editions must remain usable together. Existing editions will continue working on new compilers, so updating the compiler and adopting an edition are separate operations. Most new features will also remain available independently of the selected edition.

Warnings provide the migration mechanism. The roadmap requires warning-free code in one edition to compile with the same behavior in the next. Edition warnings should have automated fixes through rustfix, with only a small minority of crates needing minimal manual work. This gives the compatibility promise an operational meaning. A project can resolve migration warnings before changing its edition setting, while its dependencies make their own choices.

Async proposals expose the remaining design work

One concrete example of the work surrounding the recap is withoutboats' April 6 async proposal. It introduces RFC 2394 for language notation and RFC 2395 for the standard-library support. These are proposals at this date. Their design allows borrowing across suspension points, a requirement with consequences for how futures occupy memory.

Calling an async function would immediately return a future without executing its body. Polling would advance the state machine through its await points. That rule avoids an additional execution phase in which an async call performs some work before returning its future. The author chooses it because the execution model is easier to explain consistently.

The proposed standard-library addition is deliberately small. It includes the Future trait and supporting task machinery, while event loops and higher-level facilities stay in external libraries. The temporary await notation is a compiler built-in written like a macro because the final syntax remains unsettled. That is a useful warning against treating an edition planning report as a reference manual for finished syntax.

I still prefer Go for general APIs and command-line work. Rust's proposal interests me because it tries to make asynchronous execution fit the language's borrowing rules, rather than asking application code to abandon them.

Pinning explains why this needs formal reasoning

Ralf Jung's April 5 explanation of pinning examines the unstable API behind that borrowing design. A self-referential value can contain a pointer to one of its own fields. Moving the value after establishing that pointer can leave the pointer referring to its former location. Ordinary mutable access does not supply the required guarantee against such movement.

Pinning introduces a state in which the value must remain at its location. It does not mean that the type can never move. Movement before the value becomes pinned remains possible. Jung develops separate invariants for the pinned state and shows how they connect to ownership and sharing.

The proposed Unpin marker identifies types for which this extra restriction is unnecessary. His argument also addresses compatibility with existing types that were written without considering pinning. This is the kind of reasoning needed when a convenient language construct depends on an unsafe implementation. The application programmer needs a safe interface whose guarantees survive all the operations that interface permits.

New groups have different responsibilities

The verification working group announcement of April 5 describes an investigatory effort spanning foundations such as RustBelt and tools that analyze programs. Its immediate priorities include extracting compiler information, including types and trait implementations, and writing example specifications to inform a shared annotation design.

Those priorities describe infrastructure that verification tools need before they can offer useful checks to application authors. Compiler information gives a tool access to what a program means after language analysis. Example specifications help establish how a programmer should express a property that the tool is supposed to check. Neither priority amounts to a claim that ordinary Rust programs now receive automatic formal verification.

The recap also reports a new codegen group concerned with generated code size and runtime performance. Its public announcement is still forthcoming. For contributors interested in generated machine code, that identifies a separate effort from the program-verification work.