The Rust leadership has formed a Specification Team, a key step towards delivering a specification for a programming language that has so far thrived without one.

This is an advance on the RFC (Request for Comment) in June last year, which among other things asked the question “whether we want a specification.”

The new team has four members, Joel Marcey who is Specification Editor, Felix Klock and Maras Bos who are team leads, and Eric Huss who is a team member. Bos was the author of the initial RFC.

According to the initial post from the team, they will be guided by stakeholders including all members of the Rust language team, and others including one or more representatives from operating systems, specifically Linux and Windows. Microsoft posted early code for Windows driver development in Rust in September this year.

The relationship between the specification team and the language team is not straightforward. In C and C++, for example, a standards committee defines the language while implementers build compilers which may be only partial implementations of the specification or may extend it. Java has a Community Process which delivers an official specification. The Rust specification team though states that “the authority over definition of the Rust language remains with the relevant teams, such as the language team and the library API team.” This chimes with the initial goal of the specification team which states: “We expect early versions of the spec to focus heavily on delivering the detailed description of the current Rust version.” 

Arguably if the specification team is not responsible for the “definition of the Rust language” it is not altogether a specification team as that is normally understood, even though what it delivers will read more like specification than documentation. This matter has been debated with one community member asking, “if the final truth is still ‘whatever rustc does’, what’s the point of having a spec in the first place?” The reply from a team member was “if rustc differs from the spec, that is a bug in either one of them, and which one it is needs to be determined on a case-by-case basis.”

There will nevertheless be an effort to make the specification accessible to any Rust programmer looking for answers to language questions. The team also acknowledges that its initial work may have gaps, where it is imprecise, but expects these gaps to reduce as the specification evolves.

How will the specification be kept in sync with the language? Rust currently has a six-week release cycle, a fast cycle that could potentially leave the specification behind. “Rust releases will proceed independently of the specification approval process,” the new team states, even if this means that “the release will go out without an associated specification.” There is an attempt though to draw a line, when it comes to changes big enough to be called “language features.” The hope is that eventually updated specifications will be delivered in sync with the release cadence.

This is a first step and the notion of a complete specification for Rust remains some distance away. If and when it comes, it will be valuable. One comment today stated: “I believe the reason my employer … is stuck with C for the moment is because there is no official formal specification that we can represent in Isabelle faithfully, having a precise mathematical definition would help me make the argument for adopting Rust for verification work in our group.” Isabelle is a tool for proving mathematical formulae.

Precision is important and while the matter of specification will not trouble most developers, having one has the potential to improve the value of the language.