T-spec meeting 2025-06-05

--- title: T-spec meeting 2025-06-05 tags: ["T-spec", "meeting", "minutes"] date: 2025-06-05 discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-06-05/ url: https://hackmd.io/ypfp8EKCSquVPK0n1zSAyQ --- Attendees: - Joel Marcey - Tomas Sedovic - Eric Huss - Jack Huey - Josh Triplett - TC - Niko Matsakis - Mara Bos - Pete LeVasseur (joined late) Regrets: - Pete LeVasseur (for most of the meeting) Agenda: - Updates to the agenda? - Quick FLS status update - Naming Discussion Continued - Maintain access to spec repos - What do we do with `spec` repo? ## Updates to the agenda No updates ## FLS Status Update The FLS can now be built without any dependencies on external Ferrocene packages as we have brought everything required locally and can change them at our leisure. Ferrocene Language Specification has generally been removed from the document and replaced with FLS until we settle on the more permanent name. In matching the spirit of the [2025 H2 Goal](https://rust-lang.github.io/rust-project-goals/2025h1/spec-fls-publish.html), there has been a version of the FLS under the auspices of the Project and the latest is at https://rust-lang.github.io/fls https://github.com/rust-lang/fls ## Naming discussion continued Discussion started [here](https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-05-29/with/520954445) and continued [here](https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/On.20renaming.20the.20FLS/with/521600933). Where we generally paused the conversation from the last meeting as potentials. - FLS -> Rust Qualification Specification, Rust Compiler Qualification Specification, Rust Qualification Standard, Rust Qualification Requirements, Rust Safety-Critical Qualification Specification - Reference -> Reference, Rust Reference Specification, Rust Language Specfication Joel: Two camps: one believe FLS should have the word Specification in it and the other that don't. Main crux: people mainly in the academic space feel that FLS isn't a specification. Ralf is pretty dug in for the word "specification". Niko: We should have a single doc called Rust Specification. Nothing else. Why can't we? TC: The proposal that was on the table was that we'd call the Reference the "specification of Rust" and flag that people who want a document for qualification should use the FLS. If we want to merge the documents, though, it's not clear we should be pointing people doing a new qualification toward the FLS when we've completed a lot of work to make the Reference ready for qualifiction. This then led to a discussion, e.g. with Pete, about why that is hard, and also why ever merging the documents will be hard. Niko: That's why we should merge and preserve everything in the FLS and build on top. Joel: Short-term have two docs but get to one converged document at some point. But provide value sooner rather than later. We can have 2 specifications -- one towards the language, the other towards the compiler specification. Mara: Everyone agrees we should have 1 doc. But what's the timeframe for that? If we can do it in a month or two, sure. But if it's going to take longer, we'll need to name FLS -- make it clear that it's a doc owned by the Rust project. Add a note in the Reference saying "if you need a spec for qualification, use the [insert document name here]" Niko: I'm talking about the next goal -- to have the Rust Language Specification. That means constraints on the design: be approachable, but preserve the value FLS has. Agree that in the interim there will be two documents and we'll need to change the FLS name. Disagree with Ralf that this is a huge problem for the academics field because every other specification is what we're doing this here too. JoshT: The proposal from last week was to say: "The combination of The Refrence and FLS is a specification for Rust". If you're looking for a doc for qualifications and safety-critical specification, look at FLS. If you need a human-readable reference look at the Rust Reference. And make sure the docs both specify which is for and link to the other one. This would pave the way that in the future there may be one document but not promise any timelines. Joel: I'm not suggesting the rename, but I think the Reference is in such a good place that we could call it The Rust Language Specification. TC: The Ada specification is called the "Ada Reference Manual". I don't feel compelled to rename the Reference. But I agree, of course, on the general point that the Reference is in a great place. Niko: Agree with TC. But why not set a goal and a timeline? If we think it's the right thing to do? JoshT: Having a goal doing it long-term is entirely reasonable. The current purpose of the FLS is to do qualification for Rust. We don't want to break it for that purpose. But in the process of merging them, we want to make sure we don't break the tooling or qualification path or the human readability of the Reference. Achieving that (including the huge potential human and financial cost of re-qualifying the document) is going to take time. JoshT: But is that the most important thing we should be doing? Or should we set up the tooling and process to be able to ship the Qualification Spec in the same way as the Reference is integrated into our processes when people make changes to the language. There's only so much time we have, what do we prioritize? TC: I'd love to have one document too. At the same time, I'm convinced the document is going to be based around the Reference. But then, if our plan is to merge the documents, we need to ask to what degree we need to keep digging, in terms of pushing people doing new qualifications toward the FLS. Niko: If we're all agreed on this north star thing, talk about what we'll be doing in the next six months. Let's write it down -- could be a compelling argument for me. Re: resourcing: agree, we have to be realistic. Want to think what's the right thing to do for the Rust Project. But let's get clarity on what are we trying to do and achieve. Niko: number one goal: give people the ability to safely build against the specification. FLS wasn't that because it wasn't blesed by Rust. Number two was ?? (specification?) Joel: If we do come to the consensus on what we need to do, we can see if the people providing resourcing buy it. If they do, awesome. If not, we'll need to adjust. JoshT: What Niko said around having clear processes is what I was advocating for. Getting it into our processes, making sure that's a first-class document. I agree with the premise that we should have a long-term plan of merging them. But that's not a pre-requisite for saying that the combination of the documents is a specification. What reasons do we have or not to call the combination of the docs a specification? JoshT: Given that shipping the specification is the charter of this team, what are the concerns? I want to address those concerns. Mara: The result should be the Reference and integrating all the good stuff from the FLS. But what we need to do now is taking the FLS serious and giving it a name that's about the Rust language, not the Ferocene language. The current situation is that we have two documents, so we need to acknowledge that current situation, even if the future goal is to have a single document. TC: I want to go back to what Joel said, that we could put together a plan and then go try to get resourcing around it. I think that's the right idea. The plan should be explicit, then, about the resources that it needs (and should be contingent about getting those resources). We then need to also do the investigation to determine that the end state is possible and sustainable for the Project. We need to reach out to the people like Pete with background there. In having one document, we'd be accepting some constraints around how we manage and change that document, and we should understand those. If we're not talking with the assessors directly, I start worrying that we'd be in a game of telephone, and that we wouldn't have a good feel for them. That could mean that we make mistakes in either direction -- making changes that we shoudn't, or getting too gun-shy and not making changes we should. Niko: I don't agree that the Rust Refernce is necessarily the target document. We can adapt to any tooling. They only reason I care about tooling is if it costs a lot of money to migrate to mdbook from sphinx. How do we make sure to respond to the needs of the stakeholders is a good point. But we'll have to solve this eventually. Niko: If we put off the question on how we merge them, the longer we'll have new content produced and it'll be more difficult to put it together. Put some option sketches below. JoshT: It's reasonable to first document the state of the current things. We can even just say: if you're looking to qualify Rust for safety critical purposes, you can look at this (FLS) document which has been used for that in the past. People enthusiastic about changing the tooling ask Ferocene folks to ask how much that would cost. E.g. merging the FLS into the reference is not as clearly the right thing as it may sound. JoshT: Can we write down the current state of the world first? JoshT: The concerns people brought up were: does everyone understand what the word "specification" means in the same way, and are we incurring obligations we don't understand by using the word. We should write down what we mean and make that clear in the documents. Joel: Even if we do have a plan to converge the documents, we're still in the situation that we have two documents now and we need to name FLS to something other than "FLS". I'd rather manage any confusion with the current framing of the document as a specification. Haven't seen a compelling argument to not keep it the way it was branded ("Language Specification"). Niko: 2 conversations happening at the same: (1) naming (or short-term goal) and (2) the long term goal. Looking at the next month: it's clear we have two docs, clearly we need to have names, not call it "Ferrocene". Is anyone agaist naming it "Rust Safety Critical Specification" TC: I have fewer concerns about that name than a similar one with "qualification". But I prefer Pietro's suggestion of using the word "requirements". Niko: We should collect who has issues with the proposed names and what the concerns are. JoshT: The name "Requirements" needs clarification "requirements on whom from whom". Whether we call it a speficication, requirements, reference manual or whatever: whatever we're calling it we need to say: "If you're looking for a specification, look at these two documents. If you're looking for safety critical specification, look at this. If you're looking at a human readable specification of the language, look at the other one". JoshT: I'd like to reopen the original proposal from last week's document: send 1 PR to the Reference, 1 PR to the FLS describing what they're for and 1 PR to the document index and have these two called/referenced a specification. TC: On Niko's point about merging in favor of the FLS, it's more than about tooling (though I think that does matter). The bigger concern is where these documents are starting from. Both the Reference and the FLS contain claims that are true about the current version of Rust. But the Reference additionally has claims that are believed true of all future versions of Rust. The FLS has not been careful about this in the way that the Reference has been. There's a third meaning of specification that neither document addresses, which is the converse, that "if your implementation meets these claims, then it is Rust." That's not what we're doing, but we should be cognizant of that interpretation alse when we do naming. TC: I'm more interested in how we frame the documents rather than how we call them, as long as what we call them doesn't exceed how we're framing them. But if we're planning to plan to merge them short or medium term, then I start getting concerned about continuing to push people toward the FLS. Joel: I will be the one who be the "difficult" person in the room who feels super strongly that the FLS should be named as a specification. In the spirit of six in one, half dozen in the other, I don't see a compelling reason to change it. And in that spirit, let's just keep the name that everyone currently knows, and that is "specification". Joel: I do think it is fair that we ping the Safety-Critical Rust Consortium for their feedback on the naming of the FLS too, if we feel it is necessary. JoshT: Before we ping anyone, we need to have concensus on whether we're even renaming (and to what). JoshT: If anyone is proposing a short-term or even a medium-term schedule for merging, there's been enough feedback saying that this will be a huge effort. Anyone proposing it should prove that the proposal is actually valuable. In the meantime we have we have two documents. Pete LaVasseur: Pietro had a good observation and shared a lot of worthwhile thought in the zulip thread. ## On naming * Goals (not clearly all achievable) * Convey that this is "The Rust Specification" for the purposes of safety critical systems * *Ferrocene language specification* raised questions of how it relates to *Rust* and created awkward framing, e.g., "A toolchain for Ferrocene" etc. * Don't want to take a great name that we can use later for the merged result * Minimize confusion and cost for the following people (in order of precedence) * Safety Critical community and in particular assessors * Rust contributors * Academics who care about Rust * General public * Resolved * Do not rename the Rust reference * The name "FLS" is not adequate * The name "Rust Specification" is non-ideal because we may wish to use this later for our golden future * Options (and notes on them relative to the goals above) * Rust Language Specification for Safety Critical Systems * Rust Safety Critical Specification * Rust Language Requirements for Safety Critical Systems * Contention that not using the word "specification" will induce more confusion * Rust Qualification Specification * Rust Qualification Requirements * Rust Safety Critical Requirements * Contention that not using the word "specification" will induce more confusion ## Possible end of year goals... ### Option A: Combined document that we can extend going forward * Consider a few options to what a combined document looks like * Invest time in merging the content * Q: * What do we do with the language changes we'd like to make in the meantime? * What changes do we make? ### Option B: Clear sequence how changes flow from RFC to Safety Critical Spec * Declare that * The Rust specification is available in two formats? * Safety Critical Spec * Rust Reference * If you want to qualify Rust for safety critical purposes: * the Safety Critical Spec is the normative reference. * The Rust Reference contains the same material but in a more readable format. * We are working to determine the long-term merger of these two documents. * Rust open-source developers amend Rust reference * X moves changes from Rust reference to the FLS ## Maintain access to spec repos The `t-spec` team has `maintain` access to https://github.com/rust-lang/spec (what we do with this repo is another discussion). Should `t-spec` also have maintain access to the FLS and Reference repos too? ## Spec repo future Now that we have the FLS repo and continue to have the Reference repo, what becomes of the `spec` repo? ## Jitsi Chat Meeting doc: https://hackmd.io/ypfp8EKCSquVPK0n1zSAyQ 10:03 me says:Tomas thank you for taking notes. 👍 10:11 J Jack Jack says:👍 10:18 M Mara Mara says:👍 10:22 me says:I think if we came to consensus on the plan we "want" to do with the two documents, we write that down and present it to folks that could provide potential resourcing for that path and see if we can get it. Cart before the horse. 👍 10:29 NM Niko Matsakis Niko Matsakis says:( I don't entirely agree with that; I think sphinx is quite nice ) 10:33 Niko Matsakis says:but I also don't really care that much as long as folks are happy, just want to point it out 😃 10:33 J Josh Josh says:( I don't either, in that that would incur a massive tooling and requalification cost. ) 10:33 NM Niko Matsakis Niko Matsakis says:folks here = safety critical community 10:33 me says:And building on what Mara said, I don't think that is actually a bad thing to have two documents short-term as long as any plan for merging is known and explicit. 10:35 I feel silly adding two agenda items beyond this discussion. Oh optimism 😆 ❤️ 😂 10:39 J Jack Jack says:👍 10:44 J Josh Josh says:Literally any term we pick is going to incur terminology confusion from *someone*. We need to explain what we mean no matter what we call it. 10:47 I would be perfectly happy with Rust Safety-Critical Specification 10:49 Pete LeVasseur Pete LeVasseur says:Sorry to join late! I was giving a Rust training for my company 😄 10:54 NM Niko Matsakis Niko Matsakis says:Pete I'd love to get your take 11:00 PL Pete LeVasseur Pete LeVasseur says:Sure, will chime in after JoshT 11:02 me says:👏 11:02 NM Niko Matsakis Niko Matsakis says:let's focus on 1 month 11:02