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

Meeting URL: https://meet.jit.si/rust-t-spec

Attendees:
- Joel Marcey
- Jane Losare-Lusby
- Tomas Sedovic
- Pierre-Emmanuel Patry
- Jack Huey
- Eric Huss
- TC
- tshepang
- Sid Askary
- Niko Matsakis
- Josh Triplett
- Yang Feng
- Pete LeVasseur

Regrets: none

---

Notes: Tomas Sedovic

Agenda:

- Updates to the agenda?
- FLS Project Goal Logistics @plevasseur
- Here's a [doc](https://hackmd.io/@plevasseur/BkWq2Ez_xl/edit) I started to sketch into
- The North Star @nikomatsakis
- PR Review: @TC0 @ehuss

## Updates to the agenda

### Consider moving to Google meet?

* nikomatsakis: Should we consider moving from jitsi to Google meet? We have had problems.
* Pete: I've had perennial issues with meet due to "reasons"
* Josh: Likewise: had issues with Jitsi, more issues with Google Meet, even more issues with Zoom

## FLS Project Goal Logistics

- [FLS goal](https://rust-lang.github.io/rust-project-goals/2025h2/FLS-up-to-date-capabilities.html)
- [Context](https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/2025H2.20Goal.20Review/near/533115918)

Pete: I'd like to cover a bit of next steps for the goals, e.g. potentially make them a bit more specific based on discussion which has occurred (at least the FLS one, I have some thoughts).

https://hackmd.io/@plevasseur/BkWq2Ez_xl/edit

Pete: What's there makes sense. Get more specific -- keep in touch with stakeholders of FLS, making sure their voices are heard. There may be users of the Rust Project and FLS who aren't involved. I want to get them more involved -- especially around changes we may start doing (prototyping, more formalism). Also, I'd like to solicit their participation in the maintenance process. Candidates: HighTec and AdaCore

Niko: That seems pretty aligned. Plan: a future implementer provides a change, that gets (somehow) into the spec. It's important that the team that moves the FLS has some members of the spec team. I want to make sure we have clear understanding -- we've been mostly talking in abstractions so far. Getting vendors involved would be great. But when a vendor opens a PR, other vendors, project members, assessors might not be as happy.

Pete: Yes, we want to establish a relationship, have an open dialog. When we do encounter these things, we may need to become more structured in how we do things, but an open dialog is a great way to start.

TC: I think we're going to have to set up a team for the FLS. As we found with the Reference, there's a lot of context you need to build and keep, e.g. in terms of standard of review, editorial character, etc. You have to put a lot of investment for this. Right now none of us on the Spec team have that context. I'm curious how many people here would want to build that context. The people who have that context currently are not on the Spec team.

Josh: I think it's important that there be some nontrivial overlap between FLS and Spec teams. It'd be a bad idea if the people who use and maintain the FLS were completely disjoint from Spec. We also need more information on the traceability tooling for e.g. items in the spec and corresponding tests in the language. That's something we may wish to use for the Reference as well.

Pete: Makes sense.

TC: We already have that traceability system for the Reference. There's already a traceability page and we just need to add more annotations to the existing rustc test suite.

Josh: There would be some value in trynig to align the Reference and FLS tooling.

Niko: TC, I get the sense that you'd don't see value in the FLS?

TC: Not correct. I think the FLS is a good document that serves its usecase and customers very well. And for a low amount of money we can maintain the FLS in perpetuity. Let's try and get the Foundation to bring that in as earmarked funds from the companies that benefit from this. We can serve these users best by not churning the document.

Niko: But you think it's more practical to focus on extending the Reference rather than merging our infrastructure?

TC: Yes, that's a fair assessemnt.

Jack: I have the opposite opinion. I don't think we should be trying to maintain two separate "specs". We should strive to join them eventually.

Niko: I want to step us back to talk about the next 6 months. Pete, your proposal is: reach out to more vendors, more formal coalition of the willing to maintain the FLS?

Pete: That's about it yeah. Go both to the current users of FLS and also for those that are passively benefiting from the FLS right now as a tool for safety qualification. They don't use it directly but they have interest in it keeping existing.

Niko: Does anyone object / have concerns?

Josh: I think it's a very good idea we get the FLS stakeholders involved and aligned. I'm fan of the idea of trying to align the tooling and practices as well where it makes sense. But we need to continuously make check with the actual users of the certification tooling that our efforts are still serving them. Be mindful of huge switching costs of tooling for the FLS users.

Niko: I think that's right. I appreciate both TC and Jack's perspective on the long-term perspective. For the moment though: first, do no harm. Let's learn and operate the FLS.

Pete: Concrete next step: should I draft a PR to tailor that goal based on the discusison we've just had?

Niko: That makes sense to me. Any concerns from everyone?

TC: Going around vendors in the industry and soliciting feedback would be fantastic and is exactly what we should be doing.

Pete: Okay, I'll do that.

## The North Star

My main goal in accepting the lead role is to get this team onto solid footing. To that end, I want to lay out what I see as the mission of the team, the areas where I think we have alignment, the open questions and concerns, and how we can make progress on them.

Document to review: https://hackmd.io/bXK5eQDUSTGopCouxkUCaA

### Questions/discussion

#### Inputs to the FLS

Josh: The diagram shows the FLS team taking inputs from the reference text. Historically, the folks maintaining the FLS have taken inputs from other places as well, such as the release notes. I think it makes sense to incorporate that into the process.

Eric's assessment, IIRC, also showed that there are cases where we may want information to flow back from the FLS to the reference. And conversely, we should ensure that if folks take input from other places to observe that a change needs to happen, that gets fed into the reference as well.

Niko: Good callout, I agree.

Josh: I want to make sure we capture that the FLS team doesn't get input from just a single space, even in an "idealized" model. And that there's a two-way feedback.

Niko: I think that's a significant change and an improvement over the way it's described. Don't think of a waterfall. Think we have two documents with a lot of overlapping content that we're maitaining to a high standard.

Josh: Yeah. You could also imagine a common tracking system where different teams figure out whether something needs a change to the Reference and/or the FLS. Common issue, assess whether the reference or the FLS needs changing, regardless of what leads to filing the issue. Avoid duplicating effort writing text. Share notes, etc.

Niko: Yeah, that makes sense. I'll make adjustments to reflect it, the way I see it is -- we are going to try to reconcile what it means to maintain two documents and try to evolve them to consistency (and reckoning with the costs of that).

Sid A: To me the document emphasises primarily the FLS customers. I want to call out that there's an entire world of customers (other than the "nervous CTOs"). I have some concerns around runtime semantics. There's a whole community of people trying to prove the correctness of the language. The tooling doesn't talk about that. I want to clarify whether we have a document that can be handed over to people and implement the language. Or whether we'd document the compiler as we stand.

Niko: You can read this and then bring this topic back for a later time.

Niko: I plan to turn this into an RFC. I planned Ralf as a customer. But the "nervous CTOs" are people whose needs are about perception. Also, the folks building proofs and automating tools have different requirements we also want to satisfied.

Sid A: For me, if I hand someone a set of documents can they go build an alternate compiler? That's the North Star to me.

Jack: My point aligns with what Sid is saying. Also: the "nervous CTOs" don't just like the stability. But also execs that want to make sure they don't lose access to the language and can implement a second compiler. It's also availability.

Josh: Also while "nervous CTOs" is amusing for this group, if we broaden/socialise this document more publicly, we should choose a term that's less belittling out of the gate.

Niko: I did expect I was going to have to change that sooner than later. Anyway, I'm aligned. I don't know what spec doesn't allow you to build an alternate compiler. This certainly aligns with our long-term goals. I would say that the goal of the spec is "what does it take to define a compiler that can take the universe of rust programs and executes them correctly".

Sid A: You refer to "rustc" in the discussion. For me, that's a front-end implementation. Whether it's relying on LLVM etc. is taking it a bit too far in my opinion.

Niko: rephrasing: "What does it take to write a compiler that takes rust programs and executes them correctly?"

Sid A: Perfect.

Pete: FWIW in safety-critical industries it's also deemed important to have:
* a spec
* greater than or equal to 2 independent compilers written according to that spec

#### Role of team members

TC: What's the purpose of the spec team itself? What do we expect of its members? Is it the team whose members are experts on the FLS? Is it the team that's organizing the plan and resources to build... something? This still seems the important question to me.

Pete: I agree, some sort of agreement on this point is important.
* Is t-spec a meta-team that helps organize these different efforts which are in-practice done by other teams?
* Membership that would be shared between t-spec and the other teams?

Joel: This is a chicken-and-egg problem. If we can get people joining us, we can have subteams that could focus on either the Reference or FLS. Our team at this point is small. If we find resources we can have separate subteams.

TC: If we have a separate FLS team that has that context and the people on the Spec team are not deeply involved, what is our role?

Joel: I'm saying we're still part of the same Spec team. It would be members of this team and those we continue to add to this team would work on the FLS.

Niko: I don't think this (the spec team) is the FLS team. Nor do I think it's the Reference team. It's the Spec team and our goal is to write the specification of the language. I'd set it up to have a Reference team and FLS team. There is a lot of work in authoring the text, building up tooling/processes etc. The latter is somewhat situational. I think lang-doc should move here and it should be spec-reference and spec-fls. And we maintain them and keep them in sync.

TC: I want to focus on it being clear what the Spec team does if we do have the two subteams. In my model the Spec team is focused on the project that is different from what the FLS is and different from the Reference is, which is attracting the resources to create the full language definition. That means working with the Foundation on the funding proposal, hiring people, managing the success, etc.

Jack: Right now the Spec team has a lot of things to do. But that's probably not alwasy going to be true. And that's okay. Maybe it stop existing at some point. Or it'll be like dev-tools where it exists on paper but all the work goes to the subteams. In the short-term there is a lot of work to do and I don't think we need to worry about what it's going to look like in two years.

Pete: A possible wortthwhile model: the subteams could be focused on the day-to-day and delivering value to their customers. And it's possible a "meta" team could be useful to keep the high level goals and where we'd like to be, steering towards this bright future in the distance. Having such a team could be worthwhile.

TC: As a meta point, I don't like meta teams. What makes sense for organizing a deep hierarchy for companies makes less sense for the Rust Project. In the Project, a team should have a good independent reason to exist. It's not enough that it fits in a convenient place in an org chart. This is important for having a rational basis for team membership, e.g.

Niko: In my ideal world we don't have a reference team and the FLS team, we have the Spec team. Our joint responsibility is to keep them at a high-level quality and reconciling them. Another option is having essentially three teams. My feeling is that "one spec team" -- concerned with both documents and trying to figure out the long-term path makes the most sense to me.

Niko: Going forward, I'll take feedback and iterate on this document. In the future meetings I'd like to spend a little time working on this and alternate looking at the goals. So we're spending some time on the North Star and some time on the immediate steps.

#### Priorities

TC: We talk e.g. about whether we want one document. Probably we all do. But it's a matter of priorities. The priorities I see are:

- Continuing to serve the FLS users in the way they've been served.
- Building the kind of language definition we want.

To me, having one document isn't a priority as compared to these. If the most efficient way to serve these two objectives is maintaining the FLS separately for the foreseeable future, that seems OK. We could always later supersede it and provide a mapping.

The document distinguishes a number of customers, but it seems to me that it breaks down basically as follows:

- The FLS: This serves the safety-critical community at ASIL-QM through maybe ASIL-B.
- A language definition: This serves:
- The safety-critical community at ASIL-QM through ASIL-B with a mapping from the FLS.
- The safety-critical community at ASIL-B+.
- The Project.
- The verification community.
- "Nervous CTOs".
- People who want to implement another compiler.

The conversation I'm interested to have, therefore, is how we build this language definition while at the same time continuing to serve the current FLS customers efficiently while we do that.

Niko: I'm aligned on this, but I don't know how this is different. We'll talk about this later. There are many different routes to get us towards a single unified specification. That's the goal of this team.

#### One more "target customer"

Jack: I've also heard people (specifically people at Huawei) want a spec to be sure that they otherwise wouldn't lose access to the Rust language given *other* things that could happen.

#### "Can we even achieve a single document that meets the needs of all those customers?"

Tshepang: For Reference to be usable in safety critical (automotive, medical, industrial, and aerospace apparently):
- It would need to have its gaps documented (at least as compared to FLS)
- It would need to have at least its sections have annotated tests that cover the documented behavior

#### Safety-critical sections

Pete: Would you like some help fleshing these portions out? Willing to volunteer to pitch in! :relaxed:

## Reference onboarding

## PR Review

??

## Jitsi Chat

https://hackmd.io/xEYa72CJSvqQ0iIkM8n8LQ

8:02

J
Josh
Josh says:👍

8:06

avatar
Tomas Sedovic
Tomas Sedovic says:Pete, how do you spell the "high tech" company?

8:08

T
tshepang
tshepang says:HighTec

8:09

Josh
Josh says:+1 for "first do no harm"

8:21

J
Jack
Jack says:👍

8:21

N
nikomatsakis
nikomatsakis says:rust-lang/rust-project-goals repository

8:21

nikomatsakis says:<
https://hackmd.io/bXK5eQDUSTGopCouxkUCaA?edit
>

8:23

nikomatsakis says:it trails off right at the best part! but that's ok, I'll add in a bit of that framing at the end

8:24

J
Josh
Josh says:(Is it expected that "What are the needs of existing safety critical customers" is currently blank?)

8:26

T
TC
TC says:I've finished reading.

8:26

N
nikomatsakis
nikomatsakis says:> Josh says:(Is it expected that "What are the needs of existing safety critical customers" is currently blank?)

I just didn't finish writing 😃

👍

8:26

J
Josh
Josh says:Valid. 😃

8:26

(Should we put questions in the agenda, or the end of the north star document, or...?)

8:27

As we are going down the rabbit hole of finding potential holes in the North Star document and asking questions, I would like to thank Niko for putting this draft together.

❤️

👍

8:35

PL
Pete LeVasseur
Pete LeVasseur says:Yup, appreciate ya Niko! ❤️

8:36

Pete LeVasseur says:😀

8:39

nikomatsakis
nikomatsakis says:you're no fun Josh

8:40

Pete LeVasseur
Pete LeVasseur says:Niko FWIW I am also a victim of phrasing in 30 minute docs

8:40

The spec team can oversee all this work in some capacity right? Because at some point the FLS and the Reference become the "Rust specification" in whatever name and form that takes.

8:48

me says:And members of the current spec team can be part of the FLS and Reference subteams and part of the overseers of the spec processes in general.

8:48

Pete LeVasseur
Pete LeVasseur says:I wrote this a bit in the notes, but I see the spec team as somewhat of a meta team that has all these high-level goals in mind and tries to steer towards getting them done with those spec-fls and spec-reference teams doing the work

Eventually having perhaps a spec-harmonization team working to try to consolidate things and/or spec-formalism

8:49

I think the optics of not having a spec team for work that is driving to get us to a Rust specification would be quite odd.

8:54

Pete LeVasseur
Pete LeVasseur says:👍

8:57

Josh
Josh says:(have to drop for another call at the hour)

9:01

Pete LeVasseur
Pete LeVasseur says:I can stick around to learn more 😄

9:01