--- # System prepended metadata title: T-spec meeting 2026-01-08 tags: [T-spec, meeting, minutes] --- --- title: T-spec meeting 2026-01-08 tags: ["T-spec", "meeting", "minutes"] date: 2026-01-08 discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-01-08/near/566953325 url: https://hackmd.io/hEKCD8yISUuIgRA4k_4Npg --- ## Attendance Pete Levasseur, Jack Huey, Tomas Sedovic, Sid A, Jane, TC, Pierre-Emmanuel Patry, Josh Triplett, TC ## General updates tsepang: looks like no changes are needed for Rust 1.92 release for FLS, but this needs to be verified by the rest of the team Jack: on the Reference expansion project goal we're ina good shape. I want to do an overview of type inference -- when type inference is completed each type should only have one result type etc. I haven't started that but that's on my list for the end of the project goal. I think Amanieu might look over const-eval. I think we're in a pretty good spot. Niko: What's the status of name resolution? Jane: The early resolution has been fully merged and it should be available in the current version of the Reference. I did research for late resolution. A lot of it is different versions of the same things. I'm taking a break from there. I'm trying to see if I can do the type-relative resolution. I'm hoping that will be a smaller piece of work and then look at finishing the expansion resolution. I think they shouldn't be longer than the early resolution. Niko: How does this compare to the name resolution work in the FLS? tsepang: I haven't looked at it. Niko: It sounds like an interesting question to start looking into. TC: There's a section on it, I wouldn't say it's significant in the sense that the content that Jane added recently. Niko: Do you expect to move the content Jane added over to the FLS? TC: I think it would be a good thing to do. We were talking on how to increase the similarities to be able to copy text from the Reference to FLS with just small stylistic changes. Niko: I agree, and this seems like a good opportunity to do that here. Josh: We had the conversation of "what if we included more programatic elements for validation in the Reference". E..g something like MiniRust or a-mir-formality as part of how we validate things. What would the impliccation of that be for FLS in terms of proving the requirements you're trying to meet? Pete: There are things we'd really love to do that require a more formal specification -- something that's specified to a degree that we can enumerate the UB connditions that unsafe would imply. If there's a way to get that reliably -- if it's in the Reference we could bring thhings from the Reference, put it in a spot that's good for the assessors. I'd love to have that be in the FLS but I don't think it should only be in the FLS. It should be in the Reference and then bring it to the FLS. It would help with the higher levels of criticality. Today, people are trying to use rust in ASIL B. So yes, we'd love to see more things from MiniRust etc. Niko: One topic we should be thinking about is what Project Goals we want to take. Making some progress around unsafe code from the focus of the FLS or safety critical community would be great. Jack: With the expansion it seems we're going to be in a good place in terms of content being written. Niko: Do we have a sense of what the denominator and numerator is in terms of completeness? Jack: It's hard to do this type of thing without someone being a consumer of it and saying "these are the things we found to not be complete". For example const-eval: we know there's a lot of opsem stuff missing. But for e.g. type inference, there are thnigs we know are missing but there's a larger set of things we don't know unless someone tells us. TC: Ther's a lot of issues filed against the Reference of things where we know there are things that are missing. Eric Huss also had a list of these things. At a high level, the Reference is very complete on the frontend. If you look at the language syntactically, it's got a complete grammar. We're working on some tools to check that -- we have an interpreter against the Reference's grammar that we can check againtst Rustc and Syn. Things like attributes are extensively documented. TC: As you get deeper into the language, further into the interpretation process: opsem are a known weak point. Defining what a typed copy means. A lot of the type system things. My overall view is that the Reference is a pretty good approximation of our own certainty of the lang side of the language. Where the Reference is weak overlaps with the spaces where we're weak in our understanding. Nike: Regarding goals, if I were to pick one, it would be integrating the Reference into our process more cleanly. I feel going through and trying to close every issue is probably not the right approach to prioritize. But trying to say we want to pick a couple lang featurres that are being worked on as part of other project goals and using them as showcases for the Reference work. Maybeuninit, rc etc. We'd look at what they'd need and start writing that. Josh: That's exactly aligned with the goal I was thinking: given all the conversations we were having about processes, the reference and the spec. It makes sense to talk about the integration of teams, the teams are owners of topic area -- e.g. the Types team integrated with the types section, opsem wwith the opsem section, wg-const-eval etc. Types would be up for doing that, the question is which other team would be. Niko: I was talking to Boxy and we discussed on ho we could model teh const generics better. If we take that as a goal, it's not necessarily everything Types is doing but it's a subset. TC: I suggest we work incrementally on the integration. One of our really successful collaboration was Rust for Linux. It was successful because we did it incrementally. We started on smaller things, added more people later on. If we tried to do everything all at once, that would not have work. In fact it was tried and it did not work. Similarly, on the Reference side we've got to build out a model for the formalisms. Right now we have a change in the lang in how we deal with temporary lifetimes in block tail expression. That was very hairy and it called for a formalism. Dianne wrote the formalism in Agda and it was really great for being to prove things in the model and helped us to turn it into clear English statements that we could put in the Reference. I think it would be great for going line-by-line through Agda and producing unit tests. We're talking about how to keep it all in line with rustc, how to add it to CI, how to guide Rust programmers. How do we keep it up-to-date. We want to produce little modules like this, show how they work, expand to other things (e.g. match ergonomics). We've got to start with the little pieces that start with a small integration and grow it. Josh: The work you described about doing formal modeling sounds to me like a great project goal independent of anything else. FWIW I wouldn't want to propose a project goal that would integrate everything, track down every team. My expectation wolud be to pick 1-3 very obvious active on-board teams like Types (possibly opsem, wg-const-eval). And have the goal be a demonstration how the integration could work with these teams and develop a set of best practices on how to expand it. TC: My point is n is going to be 0 or 1 Josh: That's fine, 1 is an obvious number, there's value in 2 so we're not stuck in idiosyncracies of one team. I'd start with a baseline goal with a single team and if there other teams are interested they could join Niko: I don't think teams are necessarily the way to go about it. In your case TC, you could have a goal to clean up temporary lifetimes and integrating it into spec. Boxy and I are talking about ADTs in consnt generics. Some goals would be amendable to this than others. I don't think we just have to do it with temporary lifetimes, but it sholud be people really committed. TC: I agree with this. Josh: It sounds like you're talking about the opposite direction of integration. I was arguing for making sure that the portions of the Reference that are the domain of the Types team are integrated with the Types team's processes so they can review and write those sections. And I think what you're saying is figuring out where it makes sense to add things into the Reference. These are two sides of teh same coin. If the decisions of your team might have Reference implicatios, that this team should have a hand in making sure the Reference is written. TC: Today, the Reference most overlaps with the Lang team. What I care most about is integratiing it better with the Lang team. So I'd start with us (Josh, Niko and myself) and expanding that to the rest of our team and subteams. Josh: I see where you're coming from. Many of the teams the Reference needs to integrate with would be Lang subteams. Why I'd like to try this with e.g. Types is because Lang doesn't have the added bandwidth to review all the changes and spinning up the context for reviewing this. Lang should be able to delegate this. TC: We are very backlogged team, we have bandwidth limitatios on Lang. But it's in inherent to our job of defining the language to be really clear what the we're defining. I think this is a maturation of Rust process. We're moving from oral history to being able to write things down. In mature languages, the language designers do write down the language. There's a historical tension that the lang teams was operating on an oral history. And what I'm proposing is a change from historical norms but what I'm proposing is a maturation. I don't think this is something Lang can delegate. Writing it down is not a detail. Josh: Empirically we do delegate critical portions of the language to language subteams because we don't have the bandwidth and expertise. I think it's appropriate that the language level definition of the work and documentation that this is a process that has to be delegated. Lang as the ultimate responsibility of shippnig the language. Niko: Josh what you said about turning things around made sense to me. Reviewing every change to the reference don't fit my model as much. We're going to have a champion/owner that's going to be driving changes. Those individuals will try to integrate the Reference. The question on the team is: are they prepared to help them by reviewing the Reference changes? Niko: I propose for the next meeting people should write out goals they'd like to see. I'd like to see more details. I think the champions are going to be doing a lot of work to making this scale. A part of what's making us so backlogged is that we are operating on the oral level. But that doesn't mean we have to own all the details. E.g. const generics will involve the Types team. Josh: Jack and I intended to put a sketch for a concrete goal already. Needing individuals not just teams is important. We need specific person on Types saying "I want to work on the integration with the Reference" and the Types team needs to be willing to have the integration going. So the integration needs a champion but the team needs the buy-in. Josh: I agree that we should be putting concrete proposals together. Note: The end of January is the deadline to have goal *drafts* ready.