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

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

Attendees:
- Pete LeVasseur
- Pierre-Emmanuael Patry
- Eric
- Josh
- Connor Horman
- Tomas Sedovic
- TC
- Niko

Regrets:
- Joel Marcey
- tshepang

Notes: Tomas Sedovic

Agenda:

- Updates to the agenda?
- PR Review: @TC0 @ehuss

## Updates to the agenda

Pete: What would be a smart order in which to tackle the guidelines in?

Josh: Project Goal state: is the spec team ready to sign off on that goal? (What process are we following for that this time around?)

## Project goals update

Josh: We have two goals from us:

https://rust-lang.github.io/rust-project-goals/2025h2/FLS-up-to-date-capabilities.html

https://rust-lang.github.io/rust-project-goals/2025h2/reference-expansion.html

Niko: There's still going to be an omnibus RFC. Someone from the team is supposed to champion the goal. Requests for champions on t-spec are here:

https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/2025H2.20Goal.20Review/with/530409785

Niko: Over next week we'll go over thnigs that people signed up for. And the week after that we'll schedule a meeting with people to take a look.

Pete: Next step: I should go read this, digest it to have the information and discuss two weeks?

Niko: The fact the goal was merged doesn't mean it's been accepted. This means that the goal is proposed.

Tomas: Josh you can champion your own goal.

Niko: When it's proposed by someone on the team, they can self-champion.

Niko: People on the team can raise concerns but not to raise a blocking concern. They can say that they think the goal is a bad idea and they wouldn't support the RFC if it came up.

Pete: I'm interested in the ability to keep the FLS up-to-date and I have interested in taking it up.

Niko: The threshold is pretty loose. Right now it's: "you should check in every two weeks and try to unblock it". In the compiler team it's often reviews, in this team it may be something else.

Josh: Someone should not be able to get to the end of the period and have not heard about the potential problem and learn about it then.

TC: Pete, you want to support keeping the FLS up to date if I understand it correctly.

Pete: Yes, I'll have some flex time to work in the open. Reviews, work, etc.

TC: You don't have to be a champion to do those things. A lot of this sounds just as a regular work that doesn't need a member of the team.

Niko: What TC said sounds accurate. We could also discuss what criteria are sufficient for the champions. E.g. maybe attending the meetings regularly might be a enough. I think it's reasonable for you to become a champion if you keep attending the meetings.

Pete: Okay, in that case I can raise my hand to help out.

Josh: If anyone on the team had concerns about wording or anything else I wanted to surface the goal to give everyone a chance to voice it.

Niko: The FLS goal is basically saying we're going to try to set up a pipeline where the FLS gets updated in the same fashion as before but this time happening under the auspices of the project. Extending the reference also sounds good. I'd like to talk about how that material fits in the FLS but we can talk about that later.

Pete: Would it be appropriate to digest it and maybe try to put it in my own words in the zulp thread?

Niko: Yes.

Eric: I wanted to check-in on the Rust for Linux goal so we don't forget about it.

TC: I can take it. I think the specific ask is actually more on the lang-docs so I'd suggest changing the goal to tag us instead.

## Coding guidelines process

Pete: (started screen sharing). The safety critical rust consortium -- a group of commercial entities. Interested in using Rust in their industries. They have three subcommittees -- coding guidelines, liaison and tooling (to support safety critical work in Rust).

Pete: I'll talk about the coding guidelines. We have a tool called Sphinx for doing extremely complicated things involving rendering documents, scraping documents etc. And "sphinx-needs" on top. Starting to see more usage in automotive, aerospace. The goal of these coding guidelines is to fill one of the needs of safety critical industries.

The bare minimum is to have a safety-qualified compiler (e.g. from AdaCore or Ferrous System). Having any libraries safety critical-reviewed and also coding guidelines.

Today it lives at https://coding-guidelines.arewesafetycriticalyet.org. There are different categories, I won't go into the details of what they are and why they were accepted. But there are currently standards within the safety critical space (MISRA and ??) that have some of these categories.

We're almost ready to open this up for contributors. People can contribute by opening issues. Using sphinx-needs is really nice for us, but not that friendly for drive-by contributions. For that it's better to open issues on github that will get tagged and someone can review and generate a PR automatically.

Some of us are the guideline writers for the first time. And we're interested in coming up in a ordering that makes sense and let us get our feet wet and build the muscle before we get to hardcore things like FFI.

I'm interested to hear from you all (maybe async) on what you're thoughts are.

Josh: Looking at the copule of examples of the coding guidelines, I find myself thhinking that these are things that should be enforcible by lints where possible. Being able to turn on safety-critical lints and possibly make sure they won't get modified. It would be great to be intergated into the tooling. Clippy is obvious, but if they're not too eggregious maybe they can be built into the compiler.

Pete: This was a big topic at the All Hands. Most people considering moving to Rust they need a business justification. And just having some guidelines on their own is not going to land well. Having it automated would be much better.

Josh: We could provide a lot of value by having a group of e.g. all the safety-critical lints.

Pete: The clippy team talked about profiles (e.g. safety-critical-ISO26262) and enable that. There's a lot of overlap but every industry has their specific requriements.

Josh: Broadly speaking that was also me proposing some support of this. I'd like to review at least some of these, see which ideas would work, which can be broadened up etc.

Pete: I can open a new topic in zulip and share some of these.

Josh: That seems like a great idea.

TC: How complete is the document?

Pete: It's very much pre-alpha. A lot of safety critical companies are interested in such a thing existing and less of jumping in and trying to do things. It's possible that the "clone the repo etc." papercuts are preventing this.

TC: Is it your intention that this would be a resource the Project would end up maintaining?

Pete: Yeah, that would probably lend some legititmacy. I wanted to highlight that there are categorizations according to MISRA (how critical doing or not doing a thing is). And it's possible that some categories that could be useful to a more general audience. But there are others that are more nitpicky you may not want to be burdened buy if you're writing e.g. a web app. So some of these could be deemed useful by the Project.

TC: I ask because if you're looking for long-term maintainership by the Project, and if the document is still early-stage enough that changes are possible, I'd encourage you to look into the mdbook tooling used elsewhere in the Project. From a practical point of view, this would help encourage maintainership and contributions by Project members.

Pete: I've basically picked sphinx for the same reason FLS did.

Niko: My take is mdbook is a simple platform on top of which you can build just about anything. But I also think we as a team should consider using sphinx as well.

Pete: The thing about choosing sphinx-needs can generate a needs.json that can then be brought into someone's internal sphinx workflow.

Josh: The resulting tooling there, is that what you'd also use to tie the individual guidelines that verify an example fo the guideline being followed and the tool catching it and vice versa?

Pete: There are about 20% of the guidelines are ones where you have to audit things manually. And they can link to specific checks and audit them.

Pete: Those things tend to be not decidable.

Josh: Can you give an example of a guideline that's not decidable?

Pete: Dividing by zero (by runtime values) is one that isn't fundamentally decidable.

Josh: You could imagine having a guideline that's marked as deny that wouldn't let you divide by non-constant values. And if your code has one algorithm that needs to do an divide by an arbitrary runtime value, the tooling could catch that and let you allow that one instance.

Pete: Yeah, there is a syntax where you could have something like a warning or an error and use `expect` to write the reason. It would be great if we could integrate this with our tooling.

Pete: Right now there's a lot of writing paperwork done by the engineers. Also from what I've heard from people working with MISRA is that there's a lot of work being done so people don't have to write an exception in the tool. So if there's a way for us to use that, it could be really helpful.

TC: Did you get an answer to the question you were hoping to answer?

Pete: I didn't expect an answer in the meeting. I'll ask in zulip about the ordering.

## Drafting plan/proposal for language definition

TC: This gets into the purpose of the team.

I think the purpose of the team is to manage a creation of the full language definition. That was the original idea, with the spec RFC. It's not possible for that to be done, in short order, with just the work of those on the team. So doing that must by necessity mean coming up with a plan for how that can be accomplished, seeking the resources that would make it possible, and then, in the event of getting those resources, managing the execution of that plan.

Such a plan would lay out, in detail, what the "acceptance criteria" for the final product would be, and would discuss the process of getting there. It'd identify what the harder and easier parts are. It'd talk about what questions have known answers and which would take more research or require decisions from teams. It'd discuss what the non-obvious benefits are of having a full language definition, such as enabling the statement of a soundness theorem for our type system and what benefits accrue from that.

I've reached out to a number of people who have useful insight on what this kind of document should entail, and have received interest in helping to put this together.

With this plan, we could work with the Foundation to attract the resources for it. Many have expressed interest in seeing this kind of end result. We haven't yet put these people to the test by presenting a plan in which we have high confidence and making the ask for funding. That's what we should do.

In the absence of such a plan and such resources, we have to ask, I think, "what are we doing here?" The team was originally devised to do this. As we do organizational work on the team -- decide about a team lead, membership, etc. -- it's not clear how to do that without understanding its purpose.

A team that's focused on this kind of plan is a different one than lang-docs. Conversely, if we're meaning to replace lang-docs, then we should be setting clearer expectations about members coming up to speed on and being involved with those editorial activities.

Niko: You put your finger on a real tension -- are we reading PRs in this meeting or discussing the process at a higher level? We haven't made a decision but we can't do both. Your plan makes a lot of sense to me.

Josh: I think we could theoretically do both if we time-bound them and not allow them bleed into one another.

## PR Review

## Jitsi Chat