T-spec meeting 2025-11-13

--- title: T-spec meeting 2025-11-13 tags: ["T-spec", "meeting", "minutes"] date: 2025-11-13 discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-11-13/with/555398368 url: https://hackmd.io/Nq3ZuQusSGC1kCoAZXaLKQ --- # 2025-11-13 - `t-spec` Meeting ## Attendance ### Attendees - Josh - Niko Matsakis - Sid Askary - Tomas Sedovic - Joel Marcey - TC - tshepang - Pierre-Emmanuel Patry - Jane (yaahc) (later in the meeting) - Jack (later in the meeting) Driver: Niko Minutes: Tomas ## Agenda TC: Update on the FLS team. We stood it up as planned. Got great people on it including tshepang. The first two goals are organizing the collaboration with the Reference and getting the team members up-to-speed. Found a lot of productive ways to integrate the FLS. As Rust features come in we have the Reference PRs. That's been beneficial for both teems. The FLS team takes the Reference language and tries to convert it to the FLS. And doing that they need to understand the behavior of the language. Getting involved early provides values on the Reference side and highlihts areas where the language is unclear. The FLS members are there at the time when the implementer is there and can answer questions. TC: There's a big space of possibility of what can change the language. We have an idea of which ones are about to move forward. We pay attention to those and I've been pinging the FLS team about thos. Josh: On the Reference changes, part of it was understanding the changes and translating to the FLS. For the latter do you have any materials to help with the porting process? Is there a documentation for convention changes? How does one port things to the FLS. tshepang: The process is not documented. I look at the release notes and for what's applicable, I document it in the FLS. I try to much the FLS' style. Niko: I'd like to see an example of a PR to help illustrate. TC: Sure, here's one that's currently in review: https://github.com/rust-lang/fls/pull/580 (Rust 1.90) https://github.com/rust-lang/fls/pull/579 (Rust 1.89) TC: For the previous ones my standard was lower. I was looking only if anything was really wrong. For 1.89 and 1.90 I changed the standard to the same level of correctness as the Reference PRs. TC: The second point is building up the team. If someone was struggling with the Reference PRs I'd suggest the language if someone were struggling. On the FLS I've not been doing that to have them confront the challenge and work it through themselves. I'll serve as the "type checker" to make sure the text is correct. Niko: Are we currently linking any text? TC: The FLS has not been doing that currently but the Ferrous Systems has been. tshepang: We do have a separate branch where we link the reference Niko: You're adding this spec here and on the branch you're references to the paragraphs separately. Is that all open source? tshepang: It's all public. Niko: If we wanted to pull it, could we? tshepang: Yes, you can. The license matches the upstream one: Apache and MIT. TC: The next step: getting to the point where everyone on the team can identify problems and propose language. Doing critical language analysis. Writing tests to verify the behavior. We're now seeing people writing examples on the Rust Playground to verify the behavior for themselves. We're building the team up to be good contributors. TC: This is already indirectly resulted in a change being proposed to the language. When we tried to specify const item restriction in terms of mutability for FLS 1.90, we were discussed documenting the current behavior in the Reference, Oli tried to come up with the rules, they were becoming complex so Ralf came in and proposed changing the language. This will end up removing a lot of text from the Reference. tshepang: I'm grateful for your careful reviews TC. TC: I appreciate that. You're doing great, always accepting the reviews and coming in with better proposals. Niko: Was that material already present? TC: The Reference hand a const item restriction description that was more correct than what was in the FLS. The FLS was also kind of broken in const eval restrictions and lifetime extension. The Reference didn't cover certain more ad-hoc restrictions. Theemathas found great examples to uncover these. So we added these rules to the Reference semi-recently. And that triggered the newest discussion. Niko: How closely do the FLS paragraphs correspond to the ones in the Reference? We were talking about having a mapping in the past? tshepang: It takes a while to figure way for it to fit in the FLS. TC: It varies depending on what it is. E.g. extending expressions -- the rules are very similar between Reference and FLS. The FLS wants to hang everything on the glossary entries. But now we're making a language change that could upset this or causing the FLS and Reference to diverge. We're discussing this. I suggested trying to keep the FLS language to keep as close to the Reference as possible. That would minimize the correctness checking we're trying to do. Josh: +1. Niko: That makes a lot of sense to me. In the spirit of "leave it cleaner than you got it" in order to gradually bring things more in sync. Do you think there would be value in that? TC: I always like an incremental series of PRs. We do that on the Reference too. Move the language around separately from the actual textual change. *** Niko: In the other goal there were other PRs. What are their status? TC: https://github.com/rust-lang/fls/pull/579. Jane wrote it and Petrochenkov engaging strongly. Jane and I were talking, shaping the work up. She continues to push changes to it and it seems to be shaping up. We do an office hours every week for lang-docs and we talked about how to break it up incrementally. We want to see the language added to the Reference be comprehensive and correct. But it can be incomplete with stubbed-out sections. TC: We talked about a similar thing with lcnr. https://github.com/rust-lang/reference/issues/2070. There are inter-related things that are all going to point at each other. We have stubs for things like name resolution. You could put up a chapter on the other stuff. You can say this is a stub, describe what it will talk about and then you can have a link to the chapter as if you've already defined those things. That's the form of incrementalism we're looking at. TC: Eric and I talked about how to structure this. We talked about inferred types and inferred const. We'll keep the chapter to handle the language grammar. There's also going to be a type system side. Also, we've been thinking of renaming "placeholder lifetime `'_`" to "inferred lifetime". lcnr wants to use the "placeholder" text to use in the type theory so it will be great to not overload that word. Josh: The mention of having a stub chapter when you're adding a material. That aligns with what we've been working on. We've put together tooling for having chapters/sections/paragraphs that are marked as unstable. Clarifying that the text is not final. We distinguish whether the Rust feature is not stable vs. the text itself is not stable. And we can expand the stub incrementally as we go. This gets us the ability to get structure in place and linking those. TC: If you're plan to upstream those annotations, let's have a discussion before you rely on that too much. Niko: Are you saying you like the concept but you want to check, you don't like it or you don't know what to think about the concept? TC: It's more the third, but there's some details in how they implemented it. They did it using html tags rather than Github markdown-oriented admonitions syntax. I need to talk that over with Eric so it'd be great to discuss there. I understand the motivations for it but theres' balance for some of our other goals. From an editorial side, do we need a special admonition format or put the chapter and introduction there and then put a warning-level admonition on it that set's the conext on the state of the chapter? We did that elsewhere. So we need to figure that out. Josh: The goal of that is to be able to annotate any amount of text from a single paragraph, to a section, chapter. It helps to be able to annotate with the instability marker. It's important for unstable Rust so we can explicitly state which features are unstable. It's important for unstable text when we do reorganization or stubs. It's why it's not using markdown block quote notation. Niko: I love the triple-backtick `quote` syntax for side note in Zulip. Josh: We looked at that but it didn't work. We came up `<unstable-text> ... </unstable-text>` The HTML-style tags fit with Markdown's. Markdown doesn't have any extension point so anything you write with an extension is outside of the standard. This is a way that we could provide a fenced block that works with syntax highlighting. Niko: At minimum I want to have Eric Huss and discuss this with him. But the first question is to establish shared goals. The real question is do we even want to have that ability? I think TC you said you'd only like to land correct text or stubs. We should leave this for the next meeting. Josh: I agree we should align on the shared goals. Regarding the "correct text", there's a difference between "don't land clearly incorrect text" and "don't text " Josh: There's more consideration between "is the text correct". As we refine it, we may catch bugs. But I'm pushing back on the idea that primary purpose of adding unstable text is that it's wrong. We've been looking at text that's not fully evaluated or fully complete. TC: The standard of review is not ensuring absolute correctness. We will end up merging something that's wrong. It's around ensuring defensibility. When we merge something, we need to be able to defend why we put that in the Reference. At that point it's the responsibility of us, not the author. And we so need to understand the text. Josh: I think it's worth contrasting that position and description with how things operate in the compiler. At the point of merging something in the compiler I wouldn't say the compiler is now taking responsibility in the code that it's taking the full responsibility of the code. Until a feature is marked stable, the code may get in, change, remove. Josh: We may need to decide how we decide what our shared goals are. TC: Compiler is taking responsibility when they merge a PR. They have to fix issues when they come up. If you feature flag something out, that's a featruue that can just go away. On the Reference, we can't just take it away. Niko: Looking at the PRs: we have a change to the type system, change to name resolution, change to concurrency and a fourth one. TC: Jack has a PR on divergence: https://github.com/rust-lang/reference/pull/2067. It's going great. Niko: Are all three PRs looking at the stubbing to make iterations faster? TC: I think the divergence is more contained. Jack: There are no stubs there. TC: Jane, did you want to talk about yours a little bit? Jane: Mine's going pretty well. I want to go back to modify the commits I already have. I have outlines for late resolution and type-relative resolution. But I'm trying to get the early resolution polished enough to land. And I hope the other stuff is going to be easier. Niko: Do you have any thoughts on integrating changes more quickly. Jack: I don't know. Jane: I like the idea of having an unstable feature people can see documentation about. This is different from feature development process. My experience is different. The feedback I can give is more about the contribution process itself. Going to the office hours and getting more clarity on the review process has been really helpful. Knowing the goal isn't the language be editorially perfect, you're expected to contribute correct language people can understand and you can point to why things are correct. The defensible bit makes sense to me. I wish I knew that earlier so I'm hoping we can improve docs so new contributors can get there faster. Niko: TC you mentioned examples earlier TC. Are they preserved anywhere. TC: If you look at recent text, that's been added to the Reference. We try to have an example for every claim that would be true precisely because of the claim. We try to define minimum concise examples. It's helpful to the readers and reviewers. It's helpful for understanding what the author had in mind. And it's helpful for the author for the structure itself. We want every claim to be verifiable part of the language. Niko: I'll follow-up with all of you before the next meeting. Josh: Two weeks from today is US Thanksgiving. TC: I think it's important for us to focus on the two goals and support the FLS. I see that work going well. I don't see an urgency on the other points. We have a lot to do on the concrete goals ahead of us. Josh: We've been in this situation before and letting this sit for a month will TC: I understand you feel there's an urgent problem to solve. And I'm struggling to understand what that urgent problem is. You're right, we should figure that out. Josh: Niko mentioned 1-1 conversations with folks. Why don't we check back next week that we either decide not to meet over the holidays or put out a lettuce meet. Niko: We need to decide whether we have a problem or not. I'll hold the space for the same time next week.