Progress in the Development of the Rust Language Official Specification

Progress in the Development of the Rust Language Official Specification

Several months ago, the Rust team accepted the proposal of RFC 3355, deciding to initiate the development of the official specification for the Rust language.

This endeavor is being jointly driven by Eric (maintainer of Rust Reference), Felix (Rust language team), Joel (Rust Foundation), and Mara (author of RFC).

Progress in the Development of the Rust Language Official Specification

On Nov 17, the four, representing the specification team, have released an update on the progress of this work and outlined some additional plans.

Editor:

The first step involves filling the “editor” role specified in RFC. The coordination and editing responsibilities for the specification have been deliberately entrusted to the Rust Foundation to ensure continuity of work.

Due to the lack of suitable candidates through interviews, the foundation is considering an internal selection as an alternative. Joel, the technical director of the foundation, expressed willingness to take on this role as part of his current responsibilities. Eric, Felix, Mara, and others agreed to this proposal, citing Joel’s rich experience in industry standards and technical editing, coupled with his close ties to the Rust project.

Specification Team: Recognizing that the work involved is beyond what a single editor can accomplish, a specification team, known as the Specification Team, is being formed as a sub-team of the language team.

The initial members include:

Felix Klock (team lead)
Mara Bos (team lead)
Joel Marcey (team member, editor)
Eric Huss (team member)

Stakeholders:

A list of stakeholders will be selected and maintained to serve as advisors and reviewers. The initial list includes:

All members of the Rust language team
One or more representatives from the types team
One or more representatives from the operational semantics team
One or more representatives from Ferrocene (high reliability/availability, e.g., automotive industry)
One or more representatives from Formal Methods Research and Development
One or more representatives from Operating System Development (Rust for Linux; Microsoft)

Authority and Approval:

While the specification team is responsible for drafting and editing the specification, the authority for defining the Rust language still lies with relevant teams, such as the language team and library API team. These teams should involve other teams/sub-teams as necessary, for example, raising issues, nominating issues for discussion, and requesting FCP (final comment period) approval for crucial decisions.

To allow the specification team to generate content and iterate without being restricted by approval processes, draft specifications will be formulated in a working repository. With the help of certain tools, the team will openly track which projects still require team approval and which projects are under public scrutiny by stakeholders.

Changes will be categorized as either minor or major. Minor changes are those that seem uncontroversial or trivial to the specification team, such as changes already approved by the language team, formatting and syntax fixes, clarifications with explicit intent, and similar non-controversial changes. Major changes are those that might be problematic, important, or contentious. Any member of the specification team, relevant authority teams, or any specification stakeholder can tag changes as major changes. Major changes to the specification must go through the usual approval process (e.g., language FCP) to appear in a released (non-draft) version of the specification.

The language and specification teams will strive to have at least one common member (e.g., Felix) serve as a liaison to help ensure that our understanding of minor and major changes remains in sync.

Goals:

The goal of the specification team is to create and maintain the Rust specification. The purpose of the Rust specification is to provide an authoritative resource to determine which source texts constitute valid Rust programs and how such programs behave.

An ideal specification should:

Define the semantic boundaries of a given Rust program for current and future Rust versions.
Provide version-specific semantic details associated with the specification instance.

Version-specific details can be provided directly in the specification or indirectly by delegating to other documents owned by relevant Rust teams.

Progressive Development: The team aims to provide normative constraints for both current and future Rust versions while describing the details of the current Rust version. Therefore, the team has decided to maximize the value of its work through iterative and progressive development.

The early versions of the specification are expected to focus on providing detailed descriptions of the current Rust version. Such a specification can derive from existing work results (e.g., Ferrocene specification) as it explicitly focuses on providing detailed explanations for specific Rust versions. Feedback on descriptions of these specific versions will help us understand how to formulate normative constraints in the specification in the best possible way.

Given the team’s focus on the current Rust version mentioned earlier, early versions of the specification may have some gaps where specified boundaries are less precise than necessary.

For example, stating “Unsafe Rust code may lead to undefined behavior” does not provide guidance on how to write well-defined unsafe code.

Even with this imprecision, the specified boundaries can still provide useful high-level assurances (e.g., “Safe Rust will not lead to undefined behavior”).

Future versions of the specification will add more explanatory details (e.g., “Unsafe Rust code will not lead to undefined behavior under the following conditions:…”) until we achieve the desired level of precision.

Scope:

The specification should cover at least some parts of the following areas related to Rust syntax and semantics, with certain sections possibly having intrinsic connections to specific backends or target implementation technologies (e.g., inline asm):

Rust syntax, specified through Backus-Naur Form (BNF) or some reasonable extension of BNF.
Macro expansion.
Macro-by-example (macro_rules) transcription; Hygiene.
cfg attributes.
Procedural macros; attributes and derive.
Path and identifier resolution.
Modules.
Static semantics.
Type definitions; type expressions; layout.
Type inference and type checking; subtyping.
Lifetimes and borrow checking.
Generics; associated item resolution and Trait solving.
Operational semantics of safe Rust.
Binding tables; match expressions; drop glue.
Value movement and copying; borrowing.
Field projection; method dispatch.
Operator overloading.
Operational semantics of unsafe Rust.
Memory model.
Inline assembly.
Const evaluation.
Crates and crate linkage.

This list may expand over time.

Presentation:

The Rust specification will be a publicly accessible document, similar to all other Rust documents (with the same licensing terms). The text will be written in English and will only use technical terms defined either in the specification itself or in freely available online dictionaries.

Individual items in the specification can be referenced and named: not only in hyperlinks but also within the text (e.g., “[syntax.patterns.arm.5]”). Whenever possible, these name/project references should persist in different versions of the specification.

The iterations of the specification should include renderings highlighting the differences between versions (see, for example, the Ada Reference Manual).

The Rust specification will be maintained in a format that encourages contributions from volunteers, even though the specification team anticipates having to re-license each contribution to maintain consistency in the specification.

While integrity and correctness are top priorities, the team will strive to make the specification as understandable as possible. Ideally, any Rust programmer should be able to delve into and find answers to any language issues they might encounter without needing to consult a “language lawyer” familiar with the document.

Release Cadence:

Rust releases will proceed independently of the specification approval process.

If the specification for a given version has not yet been approved, that version will be released without the associated specification. However, the team may subsequently provide a specification related to a given version.

This design is intentional. The specification work should not add new obstacles that the project needs to overcome to fulfill its existing obligations, such as the 6-week release cycle.

The team envisions eventually reaching a level where updates to the specification can be automatically delivered and aligned with the project’s 6-week release rhythm. However, in the short and medium term, the team hopes to have the flexibility to lag behind the 6-week release schedule.

The ability to lag behind the Rust release plan might be particularly useful as the specification team gradually adds new content to previously unexplored areas or significantly narrows the scope of the current version specification.

Although the specification development process will not impede releases, changes to language features should align with relevant updates to the specification.

Once specifications related to a specific version are started, changes to language features recorded in the current draft specification cannot stabilize without the specification team approving corresponding pull requests for the current specification.

Changes to language features not recorded in the specification can stabilize without updating the specification but require confirmation from specification team members regarding the corresponding features being undocumented.

By enforcing the rule that new features must be part of the specification before stabilizing, the team hopes to eliminate a major source of potential lag between the specification and Rust versions.