---
title: T-spec meeting 2026-01-22
tags: ["T-spec", "meeting", "minutes"]
date: 2026-01-22
discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202026-01-22/
url: https://hackmd.io/YZL3VHqUTZWJh8KJOlK-TQ
---

## Attendance

Attendees: Niko, Tomas Sedovic, Pierre-Emmanuel Patry, Eric Huss, tshepang, Pete LeVasseur, Jack Huey, TC, Josh Triplett, Jane (yaahc), Sid A

# 2025-01-22

## Proposed agenda

* Goals for 2026
* FLS
* Jack: https://hackmd.io/_ftJFf5oQq6VadEATDj-zg
* Josh: https://hackmd.io/6CjpEeP1Q7WL7sMI-00ZHQ?edit
* "Test dummy" projects from Niko (Polonius, Expanded Const Generics, Coinduction)

Niko: Pete & tshepang, do you want to set a goal for FLS?

Pete: The goal would be low-key, get to the point of shipping the FLS within a couple of weeks within stable release of the compiler.

tshepang: I was thinking having something before of the *next* Rust release (so have e.g. FLS 1.92 out before 1.93 Rust release)

Niko: I think the 6 weeks is a good achievable threshold, lagging by 1 release. That would be easy to communicate.

Pete: Let's have tshepang and me work together on the Project Goal for this.

tshepang: Sounds good.

## Jack's goal

Jack: More focus on documentation around what is and isn't there. Preparing a roadmap, how to get those features in, what order are they most useful in, experimenting with nightly Reference. Maybe something about contributing towards that roadmap. Also a project goal about a-mir-formality.

Niko: This is cool. Might one focus be on integrating a-mir-formality into the Reference? Deciding what that means?

Jack: That's one of the goals, yes. https://hackmd.io/_ftJFf5oQq6VadEATDj-zg

Jack: I originally thought about this around experimenting with integration. But then I had an idea for more concrete goals on what to extend with a-mir-formality. But then we want to have the roadmap. So it's less focused around the exact type of work and more

TC: I'd love to get more ways of integrating a-mir-formality in the Reference. Also the temporary lifetime extension work and formalizing match ergonomics. These are currently going in as appendix chapters into the Reference. As more comes in, we'll be looking more into integrating it into the Reference proper.

Eric: Having formalisms sounds like a good idea.

Niko: The way formality works in the moment is it defines of Rust and subset of the type?? system. We have borrowchecker defined on MiniRust. All this seems connected to Nadri's desugaring. I feel like a good part of this might be changing mir-formality to use more of a Rust subset that could be defined in the Reference as core rust and use that to define the basis for the type system.

Josh: That seems like a really good point. To the extent mir-formality defines more ways in the Reference we need a way to make sure it's not circular. The Reference would be a good place to define that. If it ends up being the core of Rust

TC: At that point we'd be calling it "Core Rust" or something. And at that point the Reference would be a good document to define it. But the Reference is less of an issue here. We need to set up a set of design documents to make this possible.

Niko: Yes to all above. As a reader, identifying Core Rust would be very valuable. For the lang team but also for users. Understanding what e.g. method call dot syntax desugars to.

Niko: I like the goal.

Jack: I think it's a bit too much to try to do. Maybe as a separate project goal but having it be part of this one is too much.

Niko: I did have it mind as a separate goal.

TC: The closer we can get the model of a-mir-formality to expressible Rust surface syntax, the easirer it's going to be to integrate.

Pete: Safety critical folks love things being written down and normative. I fully endorse this.

Niko: I feel that's also a place that could use core Rust.

Pete: Let's you (Niko) and I chat offline and we can bring back to a future spec meeting.

Josh: Can you summarize why you feel like MiniRust is so much of a worse fit than a-mir-formality?

Niko: MiniRust is an umbrella tool, a set of rules but also a grammar. I don't think we want to put the grammar into the Reference. I wouldn't want to introduce a whole another language.

Josh: That makes sense. Thank you.

## Josh's goal

Josh: part of our discussions around having an incremental revision of the language documentation. We'd have n=1 case study having a nightly documenttation integration in team's processes. We could treat the types team as a case study on how they can review the documentation within their processes, identify impacts to the language and integrating them into their processes.

Josh: So getting this coming externally into the types team. And also, surfacing issues with the language documentation into the Reference earlier. Let's make sure we have ability to merge flagged content as incremental as possible. Niko framed it as having a "nightly Reference". And that could either be the reference or be a branch for this 6-12 months experiment.

Josh: The goal is to document this every step of the process, define it when it doesn't work quite right, make it into a sustainable process with examples rather than a one-off.

Josh: I put my thoughts here: https://hackmd.io/6CjpEeP1Q7WL7sMI-00ZHQ?edit

Josh: The point of the project goal is to define and develop the process.

Niko: I listed a couple projcets I'm working on. How do you see that playing out?

Josh: Those could be good fits. The three I talked with Jack are: const generics, RTN and const traits. We probably want something that's mid-way along the process of being done. So we can co-develop the relevant Reference changes alongside the language changes.

Josh: For Polonius, I'm not sure about its shipping status. It may be a fit if we expect to ship a substantiol milestone in 6-9 month. What's Coinduction?

Niko: It's a change to allow cycles in trait impls more generally.

Niko: Polonius and the cycles, I'm not suer they're quite the right fit. There's a lot of catch-up work for documenting. IT's about documenting what we have.

Josh: I suspect it's not a good fit then. Const generics might. The goal is: something with incremental milestones shipped in the next 6-9 months.

Niko: The other one is ergonomic ref counting. That's not really Types per se. It's relatively simple.

Josh: As long as we're confident it'll ship, we can make it work. I want to make sure we have something that we'll ship in relatively near future. The process shouldn't block the feature from successfully shipping. I want to make sure we're picking one that's got an excited lead who wants to make this happen.

Josh: If you think expanded const generics is a good fit and Jack thought it was a good fit, that sounds good.

Jack: I haven't asked anyone on teh Types team to check whether they'd be up for the experiment. I think const generics might be a good fit.

Niko: I already talked to Boxi and they're open to it.

TC: Is it enough for the experiment to have a const generics branch?

Jack: I wouldn't want to do this as a branch and I don't think Boxy would either. I'd rather have it as either the nightly Reference or a fork where we can make changes in and they don't bitrot because you have to constantly upgrade.

TC: If you create a new repository, it's effectively a branch. If we create the nightly, that's also a separate branch.

Josh: The branch in which there are markers for nightly/incremental text. A large part of having this is that it'd eventually be a reference. But we don't want to block this on the process of getting it directly into the Refernce.

TC: So why not create the const generic branch, then?

Jack: It's not just const generics, it's about the process. The idea is if you have multiple different features that iintegrate the Refernece into the process early, what you don't want to have a branch into them. Where each would have to maintain the integration to main. The nightly branch would mean that when there's a sync, it would integrate all the features. And having a dozen different branches with different HEAD and diffs is unwieldly and not a process that's workable.

TC: So you want to amortize the cost of synchronizing against the upstream Reference to have one team that's doing the synchronization.

Jack: That's definitely the benefit here. Like Josh said, in the perfect world it would be against the Reference proper. So there'd be no amortization.

Josh: +1 to everything Jack said. We are effectively proposing to create a branch. But it wouldn't be a const generic branch, it would be an incremental process branch. So we want to have a place where multiple places get integrating.

Niko: We've been talking about how to keep the Reference up-to-date. Josh prototyped something, there's scepticism from TC and Eric on how feasible that is. And I see this goal to be: "let's try it and see". Gather some data and see what it's like in practice. I do think it'd be pretty valuable to try it all and if it's not working, we can rip it out.

Niko: I like the idea and being able to work more iteratively. See things that aren't done, benefitting from things that are not complete yet but are there. And get the changes in. I would be interested in contributing.

Niko: I think I see some value in `n=2`, to see what happens when we have more changes at the same time.

Josh: We're doing n=1 teams - we're getting types to commit to driving this. But we should start conversations with other domain expert teams within the projects. opsem etc. And document to what extend we believe we have a process that we can generalize. We don't want to commit those teams, but we should have a conversation -- have them join the meetings -- to make sure our process is sufficiently generic.

TC: I want to support this. I want to find how to support this from the Reference side. The name that comes to mind is calling this an "experimental" branch. Is that workable?

Josh: For now, let's not block on this, go ahead.

TC: On the experimental branch, are you expecting to be rebasing against the Reference or doing incremental merges?

Josh: I'm guessing doing periodic merges from the Reference. But this is a prototype of doing something where we'd eventually do the development on the main Reference branch. Where we wouldn't do rebases/merges etc. For now it could be rebase/merge or just use a static snapshot.

TC: My preference would be you rebase against the reference. I'd also be open to incremental merges as long as they're not at random points of the Reference history. E.g. we'd pick the points when the Reference is aligned with the Rust release.

Josh: That makes sense to me. Normally, I prefer merges to rebases, but in this case where we're doing active development, those would be complicated.

Josh: The goal is to do an experimentfor a different Reference process. I don't expect we're aligned at this point on how the process should work or whether it sohuld be *the* process.

TC: So the idea is you have people like Boxy who are working on a nightly feature. And then there's some group (you, Jack) that's doing the synchronization to the Reference, keeping it up-to-date. At the end of the day when something is going to get stabilized, but then somebody is going to take what's in there and open an actual Reference PR as we're doing now.

Josh: To the extend we currently have processes "to stabilize something it must be in the Reference", what we have here is not the Reference.

TC: I understand. We're going to have to be careful to Boxy etc. so they're not going to be mislead.

Josh: We'll be clear that this is meant to demonstrate how one couldwork with a reference-like document. But it's not an alternative to not doing the stabilization Reference PRs at this point.

TC: I'm going to check with Eric and we'll get back to you.

Josh: The experimental process would involve the domain expert team hitting the merge button.

TC: So we'll fork the reference repository and that'll have universe merge rights.

Josh: Yes, basically r+ rights for anyone who has r+ rights on the compiler.

Niko: How I undertand it: I thoughtof this as a staging/experimental repo. It would have feature flags, people would open PRs. Experimental content that's feature-gated by a team would latnd with the team's approval. This is not part of reference. There would be periodic merges. To get something into the Reference propoer, there would be PRs against the Reference.

Niko: From the point of view of teh Reference maintainers, you wouldn't need to know anything about this. You'd just get a PR that may be hopefully more fleshed out.

TC: I agree. I think that's a good process here. So: we create a fork of the Reference in a new repository, assign broad merge rights for that, write down the process for doing back-merges and from teh Reference point of view we expect our normal process.

Josh: Sounds right. I've added something to the goal proposal around removing the stability markers.

Sid: Did you talk about the non-textual things e.g. MiniRust. How would that fit in?

Josh: That was in thefirst 15 minutes of the call. Jack presented a way of formalizing a-mir-formality into the Reference.

Niko: I think the output of the goal should be some periodic reporting of how it's going. I'd like to have some sense of what are the concerns we'd be gathering data on.

Josh: I'd record this as a requirement. The process and reporting are the point of this goal. If we get to this and the work we did was "we merged some changes into the experimental branch" then we failed. The work product is developing our process.

TC: Good! I'm all in favor. What do you see as the next steps here?

Josh: Getting the goal to the Project goals repository and getting it approved. And getting someone on board to do the experiment.

Niko: I'd like to collect the first drafts by the end of January.

Josh: You're expecting first drafts by the end of January. Then we can iterate before merging?

Niko: Yes.

TC: As a process matter I think lang-docs should be on this. E.g., if you wanted to call this reference-nightly, that wouldn't work.

Josh: We'd be happy to assure there are no misalignments with lang-docs such that lang-docs is not involved. I don't want this goal in any way slow down / impede lang docs and vice versa.

Niko: I think it'd be reasonable to have a vibes request from lang-docs. I'd like a heads-up. If this became a blocking issue, we'd talk about that then.

Josh: If there's a way of listing the support level of "non-blocking vibes", then I'm in favor.

Niko: I think there's high value in having a blessing from lang-docs.

Josh: I'd value the blessing, I just don't want to block on it.