---
date: 2025-08-07
url: https://hackmd.io/bXK5eQDUSTGopCouxkUCaA
---

# Rust Spec Team North Star

# Mission

"Creating and maintaining the specification for the Rust language"

# Areas of (hopefully) alignment

## What is a "specification"?

I understand a *specification* to be a definition of

* *Rust syntax* -- what is the grammar accepted by the Rust compiler?
* *Rust static semantics* -- what checks do we perform at compilation time? What programs are expected to be accepted, and which produce compilation errors?
* Related work: a-mir-formality pretty heavily.
* *Rust dynamic semantics* -- what happens when you run a Rust program?
* Related work: MiniRust.

## What is the role of the specification team?

We do not make normative statements or decisions about the above topics. Normative decisions are made by the following teams:

* *Rust syntax* -- lang
* *Rust static semantics* -- lang, types
* *Rust dynamic semantics* -- lang, opsem

Our role is to document decisions and clarify ambiguities and inconsistencies.

## What are our goals with the specification?

We aim to achieve (unordered)

* *a tool for better inter-team communication and quality assurance*
* We lack a clear way to document what the language *is*. Numerous stabilization discussions have uncovered deep misunderstandings -- and in some cases failed to uncover them.
* The compiler test suite is extensive but ill-organized. It's difficult to be sure whether all edge cases are covered.
* *Hypothesis:* Reviewing spec text that is linked to test cases will help with these challenges.
* *a reputation of maturity and readiness*
* Lacking a specification gives Rust an impression of immaturity. This leads some users who would benefit from Rust to choose not to use it as a risk-avoidance measure.
* *a radically cheaper, more effective approach to safety critical development*
* Rust's emphasis on memory safety and reliability is a great fit for safety critical development. It also produces software that is amenable to automated reasoning, raising the possibility that re-certification could be done much more cheaply than is possible with today's approach.
* To make this a reality, we need Rust to

## Who are our target customers?

Our customers are

* *Rust team members who are designing the language's syntax and static/dynamic semantics* (lang, types, opsem).
* *Observations:* It's easy to make grand plans, it's harder to build processes that are simple enough that people actually follow them. We've established that the reference is
* *Safety-critical developers and assessors*, who are building out and deploying software in Rust today.
* *Observations:* Thanks largely to the pioneering efforts of Ferrocene, Rust has acquired some momentum here, and there is beginning to be a cottage industry supporting Rust development (off the top of my head Ferrocene, AdaCore's offerings, Green Hills Software (I think), and doubtless others).
* *Researchers and developers of automated reasoning tools*, who need a basis for deciding Rust's semantics.
* *Observations:* The needs of this group are somewhat ill-defined, but their influence is real, and their concerns are justified. They want confidence that they are building on a solid foundation that will stand the test of time, ultimately.
* *Nervous CTOs* who, although they would benefit from Rust, opt against it because of a perception of immaturity or lack of a specification.
* *Observations:* The needs of this group are somewhat ill-defined, but their influence is real, and their concerns are justified. They want confidence that they are building on a solid foundation that will stand the test of time.

## What are the tools we have at our disposal?

We have two existing works with distinct strengths

* The *reference*
* The *FLS* (nee Ferrocene Language Specification)

## What are the needs of existing safety critical customers?

This is a bit more complex, but here is how I view the space:

*

## What are our short-term goals?

We have established two 2025H2 goals

# Open questions

Here are some of the areas I see disagreement.

* How
* What kind of final document we expect to produce?
* Can we even achieve a single document that meets the needs of all those customers?
* How can we reconcile the needs of existing safety critical

# Proposals for discussion

## Team design axioms

I have tried to capture my thinking into a set of design axioms for 'how we work'. The intent is to use these to resolve decisions. They are ordered, with earlier principles serving as "tie-breakers" if we must prefer one over the other. Feedback welcome.

* **Steady, incremental progress.** Let's avoid getting bogged down in abstract debates. Focus instead on "shovel-ready" projects. If we need to pick a direction, let's do so by examining proofs-of-concept.
* **Be realistic about resourcing.**
* **Nurture the safety critical space.** Rust has a lot of potential in the safety critical space and we have a quality reputation thus far. We should support these early projects.

## Target for end of 2025H2

I think our meta-goal for 2025H2 is to setup a pipeline that enables us to continue growing the reference and the FLS while we work out the shape of the eventual specification we aim to produce. I believe the pipeline we should establish is:

flowchart TD
  FeatureImplementation["Feature implementation"]
  DraftReference["Reference draft text"]
  Reference["Reference final text"]
  FLS["FLS"]
  Assessor{"Assessor"}
  Certified["Certified toolchain"]
  
  FeatureImplementation -- Implementor writes --> DraftReference
  DraftReference -- LangDocs writes --> Reference
  Reference -- FLS Tiger Team adapts --> FLS
  FLS -- Vendor takes to --> Assessor
  Assessor -- Vendor prepares PR <br> with feedback --> FLS
  Assessor -- Once approved --> Certified

What we need to make this work:

* Figure out who this "FLS Tiger Team" is:
* I believe they should be members of spec team
* Gives us first-hand knowledge of what is required

## Target for end of 2025H2