T-spec meeting 2025-10-30

--- title: T-spec meeting 2025-10-30 tags: ["T-spec", "meeting", "minutes"] date: 2025-10-30 discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-10-30/with/547960131 url: https://hackmd.io/r6VyC3IAQX2s6_DK7Eo6iQ --- # 2025-10-30 - `t-spec` Meeting ## Attendance ### Attendees - Pete LeVasseur - Niko Matsakis - TC - Pierre-Emmanuel Patry - Elle - Eric - Sid Askary - Jack - Tomas Sedovic - Josh - Jane - elle (0xllx0) ## Agenda - Spec meeting planning - Lots of confusion here - Niko's proposal: - 30 min - every 2 weeks - register on the teams repo to clear it up - Action item: - Niko to put this on his calendar and make sure it's correct - Kick-off of `t-fls` and `t-fls-contributors` - We took a goal to [develop the capability to keep the FLS up-to-date](https://rust-lang.github.io/rust-project-goals/2025h2/FLS-up-to-date-capabilities.html). We have decided to charter the team in under T-spec. - What are the blockers or next steps here? - Plan to foster reference contribution - We took a goal to [expand the reference coverage](https://rust-lang.github.io/rust-project-goals/2025h2/reference-expansion.html). How can/should we do this? - Very concretely, how can Niko (and others) get involved? (Who else is interested?) - How do we see the flow of new feature development being integrated? Should we prioritize coverage instead? ## Open questions - Longer-term, trajectory discussion - From what Niko sees, the current "plan of record" is that the spec goals are split across two documents - the reference aims to be the document that the Rust contributors + maintainers uses internally to reach consensus and shared understanding of what our language means - the FLS track "stable Rust" for consumption by the safety critical community, auditors, etc - What is the role for T-spec? - We likely need T-lang to make a decision on what they want. - Is the reference + FLS enough for stakeholders? (And, do we have a clear idea of the different *requirements* for those stakeholders?) - We have heard from Safety Critical folks, and some discussion on Zulip re. formal verification; what about others? - In our "ideal" world, how does the spec work integrate into the Project's processes? - How does the work interact with e.g. feature development processes (e.g. RFCs, implementation)? - Can we get some involvement from compiler, types, and/or opsem? How can build a "spec" that works for everyone? - What does the tradeoff between "completion", "correctness", and "usability" look like? - Different stakeholders may need different things. **Note**: The open questions section is meant not to *answer* these questions, but to help get consensus that *somebody* has these questions and work towards figuring out how to *answer* these questions. ### Spec meeting planning Niko: We should move this to every two weeks (aligned to today) and keep it to 30 minutes Jack: Rather than meeting every two weeks, we should say "first and third Thursday of every month" TC: It's better for Pete and myself to have it be every two weeks, as we have another meeting scheduled in this slot. Tomas: Here's the calendar PR <https://github.com/rust-lang/calendar/pull/98>. ### Kick-off of `t-fls` and `t-fls-contributors` Pete: We'll meet for the first time tomorrow as team and contributors. There's been activity from a couple interested folks. I'd like to invite them to the meeting. We try to make an FLS release based on the current Rust (1.91) release. To understand the gaps, processes. We'll try to read the glossary. Niko: What is the release process? Pete: Go to release notes, look at Reference PRs, look at patchsets, cross-reference the FLS, check the relevant portions and things that need changing. Lints etc. are out of scope of FLS. Niko: Where will this new release appear? https://rust-lang.github.io/fls/? Are we up-to-date apart from 1.91? TC: We're up to date with 1.89, and there's PR for 1.90 that needs more work. When we speak of the release process in this context, we're not focused on the process of generating the artifacts but on updating the FLS with new releases of Rust. Niko: Is there a plan to cover the 2024 edition? Pete: The current main user of the FLS doesn't need it, but we should do it now that it's a team effort. We should evaluate it. Niko: What help do you need? Pete: I need to make more time to become familiar with the FLS, understand what's been done, understand what's there. We're close to getting the team kickstarted. Niko: Is it possible to pick up a simple item from the release notes? How do you plan to divide it up? Pete: We'll discuss it tomorrow. We'll probably create tickets from the release notes people can pick up. Niko: We do something like that for the Reference, don't we? TC: In the rustc-dev-guide we document that a stabilization PR must have a Reference PR. This is included in the stabilization report template and in the tracking issue template. ### Plan to foster reference contribution Niko: There's been a lot of discussion about the process, how the reference should look. But I'd like to see Eric and TC talk about how they envision getting this goal working: https://rust-lang.github.io/rust-project-goals/2025h2/reference-expansion.html Jack: FutureWei people. Josh: The nature of this goal is to ramp up on areas that need diving in to understand. E.g. jane looking into name resolution. Becoming an expert in the area and then using that expertise to expand the Reference. TC: Three of these have become PRs now: name resolution, concurrency, and divergence. Eric: There's a fixed number of areas we agreed to get updated. Not sure how many people are working on what. Josh: Bunch of designated areas; some others that may become relevant. About 2/3 to 3/4 of areas have people actively working on contributions. We're all for people joining in -- we have plenty of items where people could use their expertise and contribute. Jack: [Tracking issue](https://github.com/rust-lang/project-goal-reference-expansion/issues/11) * https://github.com/rust-lang/reference/pull/1996 * https://github.com/rust-lang/reference/pull/2055 Eric: My understanding was we'd have five things to work on: type inference, trait solver, name resolution, macro expansion and const eval. If there's more, that's an expansion of scope. Josh: The project goal also had items of looking at the FLS and other areas. It explicitly said we weren't looking at opsem. Josh: Name resolution is covered. Type inference is in progress. Jack: I'm working on type inference. I started on divergence but I'll do other things too. [Relevant issue](https://github.com/rust-lang/project-goal-reference-expansion/issues/2). A lot of it is in there. lcnr also has a draft for trait bounds. Pete: (Was unclear on if this [PR](https://github.com/rust-lang/project-goal-reference-expansion/pull/7) fits in with above.) Eric: The plan is to add more things as part of this goal in terms of comparison to the FLS and other areas that are missing. That wasn't my understanding of the scope of the goal. Josh: The phrasing was: "some of the areas". The intent wasn't to make the scope too narrow. The idea was to close all the gaps in the Reference other than opsem and the borrow checker. The expectation was to heavily contribute to the Reference and provide review capacity. Niko: Some items clearly within, some may be less agreed upon on if within scope. What can we do, what's needed, what are the challenges? Josh: Some of the gap/concern: contribution process discussion. Here's a bunch of material being used as raw material. And the reviewers heavily rewrite. TC: That hasn't happened on things like adding a whole new chapter. Josh: Speaking more generally on past process. Iterate substantially, may involve heavy feedback process. TC: There are many different categories of contribution, and I don't think it's helpful to conflate these. Josh: If the expectation was: this material would be treated as similar other contributions to the reference (i.e. 50% work done by the Reference team as opposed to 100% done by the contributor). TC: When we get a PR from an author that's adding a handful of rules to the Reference (and where it's likely that author will only rarely make Reference contributions), we as the maintainers mostly just need the facts, and yes, sometimes in those cases we do a lot of copyediting to get it shape. However, when someone like Jane adds an entire new chapter, and given that you have a team focused on doing this, that's a different situation. We're expecting more of the work to happen on your team's side. Josh: The level of expectation should be to get to the point of writing the full PR without heavy editing from the Reference team. TC: That's what Eric is getting at. If you look at project goals as a mechanism for allocating the bandwidth of the team, then trying to land a PR on concurency (not in the goal) will require a lot of back and forth (do we need the chapter?, is it well-organized?, etc.), and that bandwidth wasn't allocated, and it's hard to say how that should be prioritized. Niko: This is a good point. It seems clear that for next time, we should do as much of goal planning up front and execute once the goal is accepted. And not be as open ended. These five chapters would be great and seem like the highest priority. Question to Jack about divergence. To TC and Eric, going forward we'll want to adopt a more incremental approach to landing things in the Reference. Josh: The project goal had a callout on the reviewer capacity was that we're not just going to write a bunch of material onto the reviewer. We're here to getting to the state of these contributions being higher quality and low review effort. Spreading some of the knowledge gained internally from the reviews to support improving the process of contributing to the Reference. Trying to address the contribution process is something we're hoping to be able to improve. Currently, process as documented is different from process as practiced. Eric: Niko, what did you mean by "incremental"? We've been doing that with Jane. We've been discussing things with her, she opened up the plan. Niko: I'm glad to hear that. I mean I want to be sure we can land PRs .. what works best is to get PRs that incrementally get closer and closer to the goal. There needs to be room for chapters that are rougher and chapters that are polished. Eric: There are definitely rough chapters. E.g. the name resolution says it's a stub. As part of the goal we wanted incremental work. What we don't want is for people to run off and make a big PR without talking with us. Jane's been doing this correctly and talking with us. But we haven't seen this from the other PRs. Incremental PRs are appreciated, with quick cycles of iteration with reviewers in open office hours. TC: I second what Eric is saying. Jane's been great; I appreciate her joining us on the office hours. There are three PRs open. One is concurrency chapter; it gets into hard questions. It wasn't on the list -- where does it go as a priority? Is it needed at all? It's duplicating items already written up in other areas. Maybe it's not Reference material at all. That makes this a challenging PR requiring a lot of discussion. I don't think that's a problem with the Reference process. Jack's PR just came in 2-3 days ago and seems to be somewhere in the middle. It has a lot of promise, but its structure wasn't discussed with us in advance, and some things will likely need to be moved around and deduplicated with existing content. Niko: I haven't looked closely enough to say yet. I'd like to see PRs landing and have follow-up PRs rather than being iterated on. I've seen a lot of Reference PRs open for a long time. TC: There's a selection bias here. The ones we see on the lang side tend to be the most challenging. The one about panic handling is the one that I'm sure stands out in all our minds (https://github.com/rust-lang/reference/pull/1226). Ralf spent a lot of time getting involved and going back and forth with batman on that. That was not a representative Reference PR in any way, but it's the one we all remember. Niko: Name resolution is also complicated; could be some value landing incremental work. jane (from chat): I'll say for my part, I think there's definitely an opportunity to merge my work on early resolution and leave stub markers for late and type-relative resolution. Josh: I agree with what you were saying about incremental merging and steps. The current policy of the Reference is that it doesn't document anything on a nightly. So PRs sit until the issue stops being a nightly feature. I think we should document nightly features and document them as nightly. Re: the concurrency PR, I don't think this is blocked on needing that more iteration/work. It did raise problems of whether the Reference should document every aspect of Rust or having a line. Here, the FLS has an outline chapter on concurrency -- we used that as a gap point to address (since Rust points out "Fearless Concurrency"). Jack (from chat): Another example of this: https://github.com/rust-lang/reference/pull/1731 is one that is been review and approved by both lcnr and I for technical accuracy, for more than 6 months now. jane: I do think my work would benefit from earlier merging. The early resolution is already covering a lot of the name resolution stuff. A lot of the logic I've documented is shared with late resolution and ?? resolution. I don't think these will add a lot more logic. It would make it easier to merge the PRs in smaller stages. Start a small chapter, get it good enough to merge. And then fill in the sections. TC: That sounds perfect; it makes our life easier too. Let's do it. Sid: Maybe unpopular, but the existing t-spec team was a bit overshadowed by t-lang-docs (Reference) and t-fls (FLS). The goal of this team was to address ask from stakeholders to have specification written in scratch. Some companies have vested interest in specification being done. Now FLS will be separate. People contributing to the specification should be welcome to write what they want. Rather than chastising the team for writing things. I see stringent gatekeeping here. I.e., "how dare you" contribute. TC: We appreciate all contributions to the Reference and not taking the "how dare you" frame. The Reference has a particular scope in terms of specifying the language. There's a disagreement between the Reference maintainers (and what the Reference has been) vs. what Josh wants to see in terms of a broader scope, e.g. covering user-facing things that aren't necessary for specifying the language. E.g. concurrency, error handling, etc. If someone writes a chapter on error handling, we (the Reference maintainers) are going to push back. Josh: T-spec was formed to build a specification. First we discussed whether we should write a spec from scratch. That was dropped. Then the FLS was donated. And now there's the FLS and Reference. There's friction there. The FLS now has a team, the Reference has a team. Niko: I want to thank you all. Jane: Observing tension in goals / aims / audiences of Reference. Some goals in the mind of the current maintainers. There's not the charter for lang-docs team. It would be good to have a doc that you can be pointed to when opening a PR that would e.g. point you in the right location. Jack: My experience so far, I had a pretty good idea of the behaviour and compiler in the area. Divergence I identified as not being specified, trying to come up with the outline was a lot. That's likely going to be an experienec of a lot of people. They may have an idea of what they think is missing. But they may not have an outline of what's going on. You learn things in the process of writing. Niko: I appreciate your comment Jane. One of the threads is: how are we going to manage updating the Reference when we have a bunch of topics we know need to get there and how to land things incrementally. The feeling of having a PR landing is an important feeling and one that should happen often. The other part is: what is the table of reference, how are we going to move it forward. The primary goal is to help making language proposals, RFCs etc. more precise going forward. Niko: The next step is to talk about the purpose of the Reference doc and flushing out some of the challenges. How to integrate it into project processes. Go deep. Sid, I agree with you about being welcoming. We have things like the MCP in the compiler precisely for conflicts like these. This is normal, we should align on that. I agree with Josh we should make the Reference doc team greater than two people. It feels like this meeting was useful. TC: We have an authoring guide; we have documentation. I agree we should write more, including the things discussed to better support on-boarding and clarify Reference goals. In writing these things down, we can then have discussions over concrete points. It's just going to be work; it'll take time. I'd like to hear more about why you think this meeting was useful. Josh and I know where we disagree, and I don't think this meeting has been a representative introduction to the nature of that disagreement. Josh: I think it was a great first step. We need a lot more documentation. We need to have a conversation about who's responsible for what before we even go do the deep dive first. Is there a point in discussing the Reference in depth if that's not even our (T-spec) call? Niko: That makes sense, I'll think about that. ### Open questions (Triaged out of being covered this meeting, at least explicitly, but was handled a bit above.)