T-spec meeting 2025-09-18

--- title: T-spec meeting 2025-09-18 tags: ["T-spec", "meeting", "minutes"] date: 2025-09-18 discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-09-18/ url: https://hackmd.io/JmBQWer7SkOqh8ALl2mqLw --- Meeting URL: https://meet.jit.si/rust-t-spec People: - TC - nikomatsakis - Eric - Josh - Jack - Andrew (adfernandes) - Tshepang Agenda: - Introductions - Niko will introduce "way forward" proposal for broader discussion ## What Pete + Andrew are doing Safety Critical Rust Consortium: * Coding Guidelines * Tooling * Liaison Coding Guidelines: How do we make coding guidelines that are suitable and how do we write them in a broadly applicable way that others might make use of them? Tooling: identify and understand where tooling is needed, document what tools are available, and identify gaps that exist Liaison to standards bodies: understanding processes that exist within safety critical and coding standards, interacting with them, trying to get a 4-letter word ("Rust" --ed) listed somewhere in these standards. Pete + Andrew are on the coding guidelines team. Pete's been talking about the FLS. **WG-23**. WG-23 is a list of items (around 66 items) of things that can go wrong when you are programming a computer in general. Applies across many programming languages. You have sister documents in C, Java, etc, that address those 66 items and say which ones are applicable to the language and how they can be mitigated if needed. One of the benefits of this, much like what Alex Celeste did with the MISRA C committee, is that you can show that some % of things are not possible by construction in Rust but require tooling or processes in other languages. Could be interesting to talk about this. https://cwe.mitre.org/ TC: You wanted a volunteer, right? Pete: From what I've seen this is a very intensive process. The C++ one meets biweekly for 3h. May take some time. Rather than one person, might be better to have a "buddy system" so they can share the load. Andrew: One of the things that's a bit odd in aerospace is that they don't talk about safety explicitly. It's a process driven thing. The reason you have requirements is because they tend to lead to a safe outcome. You talk about pointer dereferencing and memory safety not because they're unsafe but because they're easy to misuse. Safety of a prog lang is preconditions/postconditions/invariants *and* how easy is it to understand. Whereas WG-23 is looking at concepts that have been kind of alien in the C landscape for decades. Different mindset, you get safety/security from your prog lang, but in aerospace people don't talk about that, safety is what you get from the processes. https://en.wikipedia.org/wiki/DO-178C ## A path forward Niko: (Reviews the proposal that he made on Zulip.) TC: Like Niko said, we talked about it, but what inspired me towards this approach is the discussion we had at the beginning of this meeting. Understanding where Pete + Andrew are coming from, the very complex sets of requirements that people have around safety critical qualifications. There's a lot to be understood about what people need from a document like FLS. In particular what moved me on it was understanding the tight feedback loop that Pete is proposing between edits to the document and talking to assessors. So that the people on the team are deeply involved on both sides of it, and so there's a tight communication there. That's always been one of my concerns about trying to manage a document from the project side that's in this loop with the assessors, is that I think it's a real problem for editing a document like this to get into a game of telephone, where you are worried about what the assessors will think but you can't talk to them yourself, so you're got some uncertainty anytime you're editing a document. People are going to get claims. What I like about this approach is getting people who are directly involved with it, I think that's going to be key to keeping it valid going forward. In terms of the duplication of effort, one thing that has really stood out to me is that it's not zero-sum. If we had the same set of people, and they have to do more effort, that's a problem. If we are asking more of the people writing RFCs (you have to edit documents), that's a problem, but if we are bringing in new poeple, serving a new community, and they are working on their own document, duplication is not such a problem. We are broadening our tent and widening our umbrella in the procss which has a lot of appeal to me. In terms of what you mentioned about aligning the documents, it's something we've naturally been doing over the last many many months, looking from the reference side. What do we like about the FLS? Some nice things, some things we like, some things we don't, and so forth, trying to pull good ideas and find the value. At the end of the day we're describing the same language. There are very different editorial choices between the two documents -- it's always "clear enough" to somebody familiar with one or both, for the same language change, someone familiar with the FLS like tshepang can figure out how to adapt a given reference PR. Corresponding on the reference, when a language change comes in, we do our thing there. I think there'll be alignment over time but it'll be an iterative process. Niko: Clarification requested: * SCRC works with assessor as unit, produces assessed document? * SCRC members working with each having their own assessors? Pete: It'll start with each member working with their respective assessors but I'd like to move towards the Safety Critical Consortium having a relationship with a specific assessor. Pete: The other thing I wanted to say is that, I think up till now, Ferrous and tshepang have done an awesome job maintaining the FLS, but it'll take a village to raise it, so I think that us becoming more involved will be important. I don't have a good model for it currently. I have a diagram somewhere showing we should be in the loop somehow and understanding how this works but I don't yet have a concerete plan around it. Josh: Briefly, this plan seems like it is writing down the thing that we have off and on been talking about doing for around a year now. Having it written down and getting to the point where we can make forward progress and stop talking about what we are going to be doing seems like a great step, hopeful that we'll be able to do that. With respect to the FLS, I'd echo the previous comment that getting the project involved with the FLS and in the process of doing so making sure that the project does not end up being the bull in the china shop with respect to not fully understanding the assessor's requirements. We would like to integrate it as well as the reference has been integrated while not creating problems that would require substantial cleanup by experts in safety-critical. Jack: I'm more than happy to have us start somewhere. What I don't want is for us to start doing things and have the end goal in mind as like we're going to duplicate everything for ever and ever. We will not eventually try to move towards something. As Niko said, if we started fresh, we wouldn't have 2 documents, I think it's difficult to get us to 1 document, but it doesn't mean we shouldn't start to move there. So certainly getting people on board is good but I don't think duplicating effort is great, reference thoroughput is a big thing for a lot of people, so if we can do things that'll eventuyally make the status quo better, more eyes on reviewing "reference today but spec tomorrow" PRs, having a better overall structure, we should think about how to do that, maybe we don't know how to get there yet, but having it as our north star, for now let's at least start with something, but I don't want to resolve ourselves to saying we'll never get there, and we shouldn't even try. But the disclaimer is that I don't have a lot of personal skin-in-the-game, I've not done a lot of reference work, happy to help in what ways I can. Lot of my opinions and I'm happy to help but maybe I don't have all the background needed. Pete: What I'm hearing is I need to lock you in a room with a functional safety + systems engineer and you'll come out dazed and confused. Generally I agree with where you are coming from, we should think about having a landing zone for this effort. We may not know how tight/wide that landing zone is going to be, but we should have an idea, by taking these steps, we can move towards having these teams be more aligned in terms of their familiarity with each document. Having a mapping available between respective sections of the document, moving towards a shared technology stack for building both documents so that while we may not have the idea that we will definitely merge them, taking these steps will at least make it easier long term to maintain both documents should we decide to go that route. You get the idea, there are certain things. Niko: I wanted to pivot us to -- let's get concrete. We've been talking with Pete about creating an RFC. I am interested in a couple of areas. Organizing the FLS team is one thing. What does Pete need from us? I'm curious to know about the test suite things; I don't know whether we've merged in the annotations. That's one area where maybe we could have alignment between the Reference and the FLS. If we go this way, then I don't see a lot of role for the spec team. TC: Annotations. Those have not been merged in, Ferrous Systems has a branch of rustc with a test suite that has hashed identifiers from the FLS annotated in many of the rustc tests. That's what they use to produce the testing matrix. I don't think we host a copy of that. I think hosting that would be an interesting project for the new FLS team, it would certainly look to me to be a priority for what the FLS team could be doing. From the reference side, we also have a system for identifying individual identifiers and referencing them. We've had ideas for how to reference the FLS tags, combine systems, I think it'd be an interesting thing for the lang-docs team + FLS team to work on, would be a natural outgrowth. Don't need to hash it out in detail now. With respect to setting up the FLS team, we've got a WIP RFC and we've got charters written. They plan to have a FLS team + contributors team. I was planning to ask Niko, Niko, do you want lang on the RFC? I was imagining this as lang-docs RFC/FCP. niko: I like the idea of it being docs, I'd cc the lang team. I'd probably put in the spec team, we exist, this is decomissioning us -- or renaming, depending on your POV TC: I'd frame it as declaring victory. What I see is, the spec team was chartered to do something we ended up not doing, really, but we instead (with Joel + Foundations' help) brought the FLS into the project, so I think we declare victory, we didn't quite do what we planned to do, but we did something else. Josh: Messaging and positioning is really important. This kind of thing gets widely read. I definitely think we should not frame it as "Decomissioning" the spec team (since that's not what we're doing), no matter how much explanation you put below the fold, the headline will be "Rust project no longer working on spec effort", even if that's not at all what's actually happening. Having read + participated in the original RFC, I don't think it said that we would write a new one from scratch, just that we would make there be a spec. One way to do that is to write one from scratch, one way is to build on others' work (Ferrocene, in this case). I wouldn't say that we didn't do what we set out to do, rather, we assessed the landscape and then did what we set out to do, created the foundation for a rust spec, the FLS (safety critical) + the reference (for different kind). I would position it as "we were chartered to create a path to a rust spec, we chose the FLS as they way to do that, and now we feel the path forward is to continue driving the specification forward, and in that regard we are moving the spec team under the lang/docs team as the best way going forward". TC: Did you mean to say that the FLS is the spec? Josh: I meant, we were charged to make sure there was a spec, and we chose to achieve that by improving the reference + importing the FLS to serve safety critical markets. We can frame it however we like but it's not a massive pivot nor decomissioning. TC: Sure. I do think the idea changed over time from e.g. what appeared in the spec team's journey, but I agree that the focus of the communiction is on declaring victory. Josh: You could also say there were 2 pivots, initially using the FLS *was* our plan, then we pivoted, then we pivoted back. Jack: I will say that dissolving the spec team sort of in some ways resolves this to not reaching that north star of a merged document, since it dissolves the responsibility, two different teams, neither of whom have the goal or oversight to have a merged document. I'm not saying it's not the right idea, what I will say, by relinquishing the spec team's "authority" -- or mission -- it says we're giving up the spec team's authority. Niko: I actually wanted to poke at that question a little more. I said that if we were starting over there'd be one document, but I'm not actually sure that's true. In what I'm hearing from Pete, the character of this document... We would always have a more accessible document. Another way of looking at it is that we set out these goals -- we wanted to have a space for teams to work together, we wanted to serve customers within the Project, we wanted to eliminate arguments against Rust adoption. You could say that we've found that the best way is having two documents -- at least in the short term it is. I see the lang-docs team as owning the goals of the spec RFC. They should try to ensure that we have * a way for teams to communicate with precision * a way to meet the needs of customer segments that require a spec * a way to defeat the (specious) assertions that Rust is not stable or ready for prod use due to not having a specification As I see it, moving the spec team under the t-lang/docs and focusing it on the FLS is not giving up on those, it's saying "the mission of the docs team is do those 3 things, either with 1 or 2 docs". Josh: I think we do have to think about what our goals are when we set an org structure, since it's easy to ship one's org structure ("Conway's Law"). We should think about our requirements and then hand off all of the responsibilities of the spec team, including the responsibility to align documents and tooling further in the future. As long as we cleanly hand off this responsibility to lang-docs, we're good here. Pete: A thought -- it may be that a single document even if created may struggle to satisfy two consumers: compiler engineers, that want to get into the exacting details; most of the Rust community that wants something more detailed than e.g. the Rust Book or an array of resources but above the level of that or reading the compiler source. Joel: I would also position it to say that the Rust Project is still dedicated to formally specifying the Rust Language. And update the charters of the Reference and FLS teams to indicate they are working on spec things, in addition to other things they do. It's quite possible, unless we message this carefully and clearly like Josh said, that not having a spec team causes more confusion than clarity. Two separate teams working on spec things will definitely raise questions. But if all of this is going to be under the docs team, then the docs team charter can hopefully help reduce that confusion. niko sketches: * merge "lang/docs" and "specification team" * name "lang/docs" as "specificaiton" * goals of that team are to * enable precise team inter-communicate on what a design *means* * enable customer segments that require a specification with formal assessment * a way to defeat the (specious) assertions that Rust is not stable or ready for prod use due to not having a specification * create a subteam "FLS" that is focused on the FLS * lead: Pete LeVasseur * goal: to obsolete itself, find the way to merge the reference TC: I'm not sure if we should frame that as the goal when we don't know if it will play out that way. I think there are natural forces that make you want one document but also practical forces pushing the other direction. Pete: I agree we don't quite know where we are going to land. Niko closes: Next steps * Pete to continue iterating on an RFC for broader review * Next meeting # Copying from chat me says: https://hackmd.io/JmBQWer7SkOqh8ALl2mqLw 15:03 JF Joel Marcey (Rust Foundation) Joel Marcey (Rust Foundation) says:audio issues 15:06 Joel Marcey (Rust Foundation) says:ok. I think I am good now. 15:06 Josh Josh says:Jack, your audio is very faint and distant. 👍 15:07 Josh says:Jack: (The last couple of words were clear, if that helps you debug.) 15:08 AF Andrew Fernandes Andrew Fernandes says:"BoB Dylan Audio" 😃 15:08 N nikomatsakis nikomatsakis says:I learned something! ❤️ 15:08 PL Pete LeVasseur Pete LeVasseur says:We should have Andrew jump in and intro 15:08 N nikomatsakis nikomatsakis says:I figured he'd go last, guest of honor 15:08 PL Pete LeVasseur Pete LeVasseur says:yay 15:09 Pete LeVasseur says:👏 15:09 Josh Josh says:👏 15:09 me says: https://cwe.mitre.org/ 15:16 me says: https://en.wikipedia.org/wiki/DO-178C 15:19 AF Andrew Fernandes Andrew Fernandes says:Aha! I was wondering how to raise a hand... 😃 (haven't used jitsi before) 15:20 J Josh Josh says:(I have confidence in the people in this room, we can get dazed and confused *much* quicker than that. 😉 ) 😂 15:34 J Jack Jack says:👍 15:36 AF Andrew Fernandes Andrew Fernandes says:👏 15:43 JF Joel Marcey (Rust Foundation) Joel Marcey (Rust Foundation) says:I would also position it to say that the Rust Project is still dedicated to formally specifying the Rust Language. 👍 15:45 Joel Marcey (Rust Foundation) says:And update the charters of the Reference and FLS teams to indicate they are working on spec things, in addition to other things they do. 15:46 PL Pete LeVasseur Pete LeVasseur says:A thought -- it may be that a single document even if created may struggle to satisfy two consumers: compiler engineers, that want to get into the exacting details; most of the Rust community that wants something more detailed than e.g. the Rust Book or an array of resources but above the level of that or reading the compiler source 15:51 JF Joel Marcey (Rust Foundation) Joel Marcey (Rust Foundation) says:It's quite possible, unless we message this carefully and clearly like Josh said, that not having a spec team causes more confusion than clarity. Two separate teams working on spec things will definitely raise questions. But if all of this is going to be under the docs team, then the docs team charter can hopefully help reduce that confusion. 15:52 PL Pete LeVasseur Pete LeVasseur says:Conway's Law is real What about the following? lang-docs hosts t-spec t-spec hosts both reference and fls teams 👍 15:53 J Josh Josh says:Best case no headline, next best case "specification team becoming more fully integrated in Rust project" 15:56 PL Pete LeVasseur Pete LeVasseur says:Headline: specification is so important it's now a team that has more responsibilities! 15:56