---
title: T-spec meeting 2025-12-04
tags: ["T-spec", "meeting", "minutes"]
date: 2025-12-04
discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-12-04/
url: https://hackmd.io/K_VjxpIVQUWcmJZuqdcOLg
---

# 2025-12-04 - `t-spec` Meeting

Attendance: Niko, Tomas, Pierre-Emmanuel, Sid, Pete LeVasseur, TC, Eric, Jack, tshepang, Jane (yaahc), Josh

Niko talked to a lot of people. Plans to bring the end-to-end flow to the Lang team. Feels the team is at an impasse now and feels we need to bring outside people in.

Jack: I agree, it'd be good to bring the Lang team and get them to weigh on this.

Niko: The goal of the Spec team is to create the document that we as the Project can use to better communicate with each other and the outside world. The people making those decisions about how we want to interact need to be involved.

TC: I think the Lang team is the obvious customer for the document, getting them involved is unalloyed good. Integrating champions in the process (so they're taking responsibility for working with the authors of features) is necessary. Niko, what other thoughts you're planning to bring to the Lang team?

Niko: I want to talk about how do we do these things, what is the right time, how do we get the people involved. I have a specific proposal but I'm not convinced it'll add value without discussing with the broader team. We need to ask how will people want to interact with the Reference?

Josh: I'd like to hear at least the spine of your proposal.

Niko: Are there any other updates we should cover?

Pete: We started to operate the way we should. tshepang added the PR of the changelist for the 1.92 release. We split those out into issues and people started working on those. See how the process will work for us for the 1.92 release.

TC: I've been really happy with how things are coming along with the FLS team. The goal is to bring the other members on the team up to the level where everyone's comfortable authoring content for the FLS. And then getting them comfortable to review the FLS content. For 1.90 updates we've made some good progress there. People started proposing language that was wrong, then realised how hard it was, then stared showing behaviours to doing it correctly e.g. writing tests. A lot of what we're doing on the Reference side when looking on a PR is identifying areas we don't understand / it's not comprehensive enough. That's what you notice on the FLS side too. When the FLS team looks at the Reference and trying to write the FLS text, when they notice there's not enough, that's useful signal for us to see early. I'm excited to have excited people on the FLS team.

Pete: That's a lovely recap, thank you for that.

Josh: To what extent you have processes or plans to how to get more people directly contributing the material. Right now the process seems to be built around what's in the release notes and what's in the Reference. How do you plan to get peopole to contribute directly when they make a change.

Pete: I want to eliminate the need for any specialised knowledge. I hope at a certain point it's as simple as copying/pasting and maybe small adjustments from the Reference PR. But if there are contributions that don't have a corresponding part in the reference, I don't see any particular barrier to endtry for wanted to contribute to the FLS. Do you have any particular thnigs you're thinking of?

Josh: It seems there's still some specielised tooling and information. A lot of process involved in the test linking and headings. The more important point is the question of integrating with the Project processes. How do you connect people making changes to Rust and the FLS.

TC: I've learned the FLS is quite similar to the Reference. Teher are some stylistic differences, the way FLS leans into the Glossary is the biggest difference. Pietro recently mentioned relying on the glossary was one of his biggest regrets. My hope & takeaway is that the fLS is very fundamentally similar to the Reference. For the most part we can take the Reference language and that's ideal to do that to lower the cost. After a lot of iteration, we ended up copying and pasting and making some small changes. In most cases it'd be great to make changes to the Reference and then bring them to FLs.

TC: Regarding contributors, I don't think there are barriers. It's an ReStructured Text (.rst) and it uses sphinx tooling. And to prodactively edit the FLS you need to read the glossary to understand the differnt terms. So if you put a few hours into RsT and read the glossary, you can start contributing. I don't think it makes sense asking people to make FLS contributions. It's morebringing companies with interest in the FLS to make the final step of transaltting things to the FLS.

Pete: My current thinking is that the Reference is upstream to the FLS. More integrated with the processo f satbilizing things in the compiler. And then FLS would follow those quickly to make changes for the assessor.

Josh: That was helpful, thank you. Good to know what trajectory it's on and what the short and long-term goals are.

Niko: I'd like to talk to you Pete more later about the assessor situation

Niko: Do you feel there's enough contributors or are you trying to actively grow?

Pete: I want us to try 1.91 and see how we do. Looks like 1.91 is a bit lighter in what's coming in. But I'm happy to have more contributors. Often there's little overlap of people of people who are online and embedded people. And there's even less overlap between embedded and safety critical people. I'm happy for more people, but I'm not actively chasing people.

Niko: Do you anticipate any need for going beyond the language. Need for nightly features? If we were to insert tooling, these tools would have to be qualified.

Pete: Yes, the tools would migrate to the FLS.

Niko: similar for core and std.

TC: Pete, is the correct takeaway that you see the FLS documenting much more of the library or nightly features?

Pete: No. It'd be scoped specifically for the things the safety critical need. E..g interest in bringing MCDC back into the compiler, insert the proper hooks so it's possible for different safety critical vendors bringing their own. These things would be very scoped.

Niko: My expectation is that overtime the functionality in libcore and supersets of it will be something vendors will want to use. One of the promises Rust offers to the safety critical community is not having to write everything with a fixed allocation. I think there will be desire to bring more features in.

Pete: Let's check back in on this. Ferrous Systems just got their IEC 61508 SIL 2 (Industrial) certification. Plans for ISO 26262 ASIL B (heapless) certification early next year.

TC: There are very widely used ecosystem things. Does it make sense to bring those in too?

Niko: We'll figure that out. We'll have an embedded working group that can evaluate commonly used things, but there seems no fundamental reason every vendor would want to go and recertify some shared piece of the infrastructure?

TC: Pete, do you know what Ferrous Sysetms did for qualifying the core?

Pete: I'll find some links and post them here.

tshepang: This is the doc for the core certification:

https://public-docs.ferrocene.dev/main/certification/core/index.html

tshepang: This is the index:

https://public-docs.ferrocene.dev/main/index.html.

You can look at the Certification Material.

TC: So the certification material is still using the core library itself.

tshepang: We use lang coverage for ASIL B. ASIL C will be branch coverage I think and ASIL D will be MCDC.

Niko: What do you mean by "lang coverage"?

(later editing: should have been "code coverage", referring to coverage for Core library)

Pete: different safety critical standards specify different types of code coverage or riggour of code coverage. For ASIL B they can use line coverage or statement coverage.

Niko: So show that the standard library tests cover a certain percentage of the lib code?

tshepang: Yes and we had to add tests to improve completeness.

Niko: And the test coverage should be adequate in terms of completion and also in covering specific

tshepang: Every bit of code has to at least be covered.

Pete: These standards are challenging to read and there are people who's entire jobs are to read and understand these.

Eric: My understanding: they set out standards of development processes: you have coverage, reviews etc. Not necessarily that you've proven everything's correct.

## Niko's feature proposal

### Major phases

| Phase | What you are doing | Transition doc | Decision type |
| --- | ---- | --- | --- |
| Ideation | Talk in workshop stream or wherever | Experiment issue (Summary + Motivation) | Champion |
| Experiment | Experimenting with impl, narrowing down range of designs, reducing uncertainty | Proposal (+ Guide-level explanation) | FCP |
| Proposal | Finishing up impl, develop reference text | RFC (+ ref-level) | FCP? |
| Preview/polish/beta | Get user feedback, try it out at scale, apply polish (diagnostics, rustfmt, finalize reference text, etc) | Stabilization report (+ updated ref-level)| FCP |
| Stable | Enjoying your shiny new feature

### "The Spec"

The Spec covers a range of normative artifacts, ranging in precision

* High-level
* Rust Language Reference -- highest-level document
* FLS -- derived from that
* Mid-level
* a-mir-formality -- types team spec, half-way in between
* mini-rust
* Low-level
* Rust compiler

### Who owns what

The reference is special in that it targets external users as well as internal users. Its content is "jointly owned"

* t-lang/docs -- editorial and style decisions, charged with ensuring it is accessible to the "advanced Rust user" and that it presents a consistent picture
* lang, types, opsem -- charged with ensuring the content is technically accurate and precise

When both teams are satisfied, we are in a good place.

### Reference evolution

Once there is a stabilized "proposal", edits can be landed in the reference.

Three ways to tag text:

* editorial approval (yes/no)
* team approval (yes/no)
* feature stability (yes/no)
* text stablity = editorial approval + team approval + feature stability

To mark text as editorially approved:... niko didn't finish typing here...

**Discussion:**

TC: This FCP is not gating the experiment?

Niko: no, the experiment just requires a champion.

Josh: The point of the table is taht the transition doc and the decision in the table is how you exit that state? A broken down step-by-step of an RFC process that transitions to a Reference process and stabilization process. The steps in the table are how you *exit* the row in the table, is that correct?

Niko: Yes, exactly.

Josh: Then in addition to a stabilization report, presumably you'll also need updates to any Reference-level details that changed during the process of getting in at the end of the preview period, right?

Niko: That's correct.

TC: How much does this tie into your proposal of doing feature previews?

Niko: My preference is, when you're in preview state the feature is usable from beta. And it can stay there as long as it wants.

TC: Peopel would still have to set the feature flab, but it would also be available in beta?

Niko: Yes, I would see it the same way as in nightly. You use the beta toolchain but opt-in on feature by feature basis.

Josh: That seems like a workable strategy, but the way you describe it is not necessarily tied into beta. We can enhance this by adding it to beta, but it's not necessary for this. We can do all this in nightly.

Niko: exactly. I expect other kinds of polish (e.g. rustfmt). I feel the bar to get into preview is: the language semantics and complier implementation are correct.

TC: I'm unclear how that would work in practice. What would we be FCPing at the stage of turning it into a proposal.

Niko: Specific example: const traits. There would have been an experiment, people implementing things. They'd put in the const syntax and there was uncertainty at the implementation level on how to do it. What happened in practice, no one was satisfied with the implementation until Michael came in and did it.

Niko: So instead, we'd write a proposal for the Lang team on how the syntax should go. How sholud the users think about this feature. The FCP there would be that we're happy with the way this syntax. And then we'd go to finalising this.

Josh: I think it's a good idea. Today, our concext of experiment is a broadstrokes handwave of an exprimant I want to try. Instead saying this is a summary and implementation of a problem. We've talked for years on agreeing on the problem first and then agreeing on the solution shape. I think this makes a lot of sense.

Josh: Last time I said I had a draft I was going to circulate. I've pasted a copy of my draft below. I think Niko's proposal is compatible with my idea. That's a potentially compatible thing. I think we should adopt the phased approach on the lang side.

TC: I need to think about it more. The problems and solutions can easily be co-mingled. I'm not totally sold on the guide level section being easier to write. For the const trait example, we'd still be stuck in the guide-level explanation becaues we haven't had the syntax.

Niko: We would have been blocked. But with the current experiment it's unclear whether having settled one half you're ready with the other. There when people were settled on the implementation/semantics but from the Lang team we always thought that "twiddle const?" thing was a non-starter.

TC: Yes, that's helpful for understanding where you're coming from. That makes sense, though I'd worry about whether we may be overrotating a bit on that one case, which was fairly exceptional. In many cases, the Reference-level explanation and the guide-level one are closely coupled. Often the arrow points the other direction, even, where it is more important to nail down the exact language change first, and then how we explain it to people comes afterward. So I do wonder whether these would always seem to us to be separate steps. It's something I'd want to talk more about.

---

# Josh's draft proposal

(Note: the "phased" process proposed above, that splits the RFC steps seems like a good process improvement as well, and would work well with this.)

## Requirements: What the spec should have

- Tests and validation
- Cross-referencing with the compiler's tests
- A process for incremental addition and improvement, that isn't all-or-nothing before being merged.
- Expert involvement - not just involvement, but ownership.
- Must not gate reference contributions on central understanding of all materials by a small number of maintainers. Need to divide and conquer in order to scale.
- Editorial integration, in a non-blocking fashion. Maintained/coordinated by spec team.
- Eventually: professional editing, via professional technical editor. This is somewhat orthogonal to the semantic correctness.
- Serves as a QA tool for validating Rust compiler code, including corner cases and discrepancies in the compiler implementation.

## Process proposal

### Setup process

- Identify teams of topic experts owning the corresponding area of the reference. (These are the *same* teams that own, or should own, the corresponding area of Rust, e.g. the people who wrote the code/designs.) T-types, T-compiler, T-opsem, others, as appropriate.
- These teams should be properly empowered through delegation of the appropriate area; they are not just "recommending" to another team or the editorial team.
- We will need to arrange more such teams as gaps are identified.
- Contributions may come from those topic experts, or people seeking to add/stabilize new features, or outside contributions.
- Contributors may wish to coordinate with each other or with topic experts, either to avoid duplication or to plan out a strategy for work. This is more important for large-scale contributions. Policy similar to the compiler: recommended but not hard-required.

### Contribution process

- When a new contribution PR comes in, the text should generally be marked as unstable (`unstable-text`, and `unstable-rust` as well if it's for an unstable Rust feature).
- Should make a best effort to integrate into appropriate sections, but in some cases (especially when documenting as-yet undocumented areas of Rust), the text may genuinely belong in a new section.
- Need triage process to identify relevant topic expert area, if contributor has not already marked it. Some tooling can help steer this (e.g. file-based), but it'll still largely be a human triage process.
- Topic experts will review and approve, and confirm that text uses stability markers, and address any obvious problems. Editorial changes at this phase should be kept to a minimum.
- Since text is marked as unstable, this process should be equivalent to an `r+`, *not* an FCP.
- Goal is to merge and iterate as long, not to substantially iterate within the PR.
- If text accurately describes *current* behavior it should be merged as unstable. Should not block on *changing* current behavior even if undesired, but that may block subsequent stabilization.
- Subsequent editorial work iterates on and integrates text marked with stability markers (additional testing, consistency, readability, etc). These changes are reviewed by the relevant topic expert team, to ensure these changes do not break the semantic meaning.
- Editorial work also includes tooling for integration/cross-referencing of compiler testsuite.
- Editorial work may include addition/referencing of new tests with verification from topic expert team. Topic experts will also often add tests.
- Need to fully define process for "stabilizing" text and removing stability markers.
- See above: this part of the process might block if a discrepancy was identified that needs to be resolved.
- Need to define process for changes to existing stable text.
- In some cases the new text will need to become unstable.
- In some cases the new text will remain stable.

## Future possibilities

Improve stability markers by adding a way to mark grammar productions as unstable, inline in a grammar, rather than having a separate grammar block.

If in the future we create a T-design (previously proposed, alongside a T-impl), T-spec would best fit as part of that T-design, alongside the other design teams.

Additional tooling for integration/cross-referencing of compiler testsuite.

Additional tooling for validation in other forms. Perhaps integration/coordination with contracts work or other formal methods work. (Need to take care that this makes the process *easier*, rather than creating barriers to contribution.)

Eventually: professional editing, via professional technical editor. This is somewhat orthogonal to the semantic correctness, though the editing can improve clarity, and would need to be a feedback loop with topic experts.

## Comments