---
title: T-spec meeting 2025-07-03
tags: ["T-spec", "meeting", "minutes"]
date: 2025-07-03
discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-07-03/
url: https://hackmd.io/sJFnKx-cQsC3bn-3xX3oPQ
---

Meeting URL: https://meet.jit.si/rust-t-spec

Attendees:
- Joel Marcey
- Sam Wright (Ferrous Systems)
- Eric Huss
- Josh
- Pierre-Emmanuel Patry
- Mara
- Tomas Sedovic
- TC
- tshepang
- Vitali Borsak
- Sid Askary
- Midia Reshadi
- Luca

Regrets:
- Niko Matsakis

Agenda:

- Updates to the agenda?
- `t-spec` team organizational announcement
- H2 2025 Rust Project Goals
- "Getting clear improvements merged" Zulip discussion
- PR Review

## Updates to the agenda

## `t-spec` team organizational announcement

Joel: I plan to step down from t-spec leadership effective asap. I'm not leaving t-spec itself, but this seems like a good time -- we're at the natural breaking point between H1 and H2 2025 goals. The naming discussion needs someone passionate about that vision.

TC: We love having you around Joel. Huge appreciation of everything you've been doing. Know it was a ton of work to bring in the FLS.

Josh: Hear hear. Whether you intended to be in it or intended to be in it as long as you did, you've knocked it out of the park as long as you were in it.

Joel: The next step is to figure out who wants to be the leader. We used to have two people, we only have one now. Niko suggested he may want to be a lead at some point.

TC: We could appoint him in abstentia... I jest. Are you willing to hold the position until Niko gets back?

Joel: Yes, I can do that.

TC: Separately, based on his deep experience pushing the Reference forward for years, I've long wanted Eric to do this, but I don't think he wants it (we'd probably have to appoint him in abstentia).

Joel: I thought about a couple of people who would be great for this. But I won't name names to not put people in an awkward position.

Josh: If you're not in a great hurry, then waiting a couple of weeks and having discussions would be preferable.

Josh: In the interest of doing a good job to select what the right person is, can we work with you to document the aspects of the job that aren't obvious? And hand that to the new person in transition?

Joel: I can put a document together.

## H2 2025 Rust Project Goals

### Reference a true superset of the FLS

Proposal: Make the Reference a true superset of the FLS

Background: The Reference has more topical documentation than the FLS. The Reference is in some ways a superset of the FLS, but not a strict or true superset because the FLS has some items not documented in the Reference.

Rationale: If the idea is to have the Reference eventually become the specification of record for all purposes (general language specification, verification, safety-critical, etc), then ensure that the Reference contains all the relevant content that the other documentation contains that is required for their use.

Goal: Utilize the FLS/Reference [gap analysis](https://docs.google.com/spreadsheets/d/1FgBYYVY3RtLHZyyy_bCQ-cWmC2nbLsbStgj1OPCeQ3E/) and choose 1+ items in the FLS that should be documented in the Reference.

Which items?
- From FLS?
- Ownership
- Concurrency
- FFI Boundaries (Already somewhat covered)
- Other things not necessarily covered in either the FLS or Reference, but should be at least discussed in the Reference. If we go down this route, we should still fill in all the gaps covered by the FLS that are not covered by the Reference.
- Borrow checker
- Type inference
- Trait solver
- Operational semantics / dynamic semantics of the language
- Exact behavior of proc macros
- Expansion in general
- Name resolution
- Review bandwidth

Josh: Tomas, what is the deadline for new proposals?

Tomas: Deadline for submitting new proposals is July 18

Josh: I planned to have a goal to improve a reference.

Joel: Is this something else than what we were talking to here?

Josh: I was thinking more of updating the Reference relative to Rust rather than the FLS (what does Rust have that the Reference doesn't have)? I have a list of about 8 things and proposed to work on about 6 of them. And trying to improve review bandwith.

Joel: Your goal is obviously needed but the question is: is our priority to bring the Reference to a point where the Safety Critical can use in a short time or just generally adding more stuff Rust has that the Reference hasn't. We need decide on priorities.

Josh: The list of "other things" in the agenda is what I planned to work on, not bringing content from the FLS to the Reference.

TC: Eric, do these three items look good to you as things that are covered in the FLS that can be moved into the Reference?

Eric: The FFI boundaries are covered. Ownership is pretty light, that can use some work. Concurrency we can talk about in terms of what we want the language to define there. The FLS documents the existance of atomic types. I thought these were mainly part of the standard library, but there are language aspects there too we want to cover.

TC: Josh so what you're proposing here, who's going to be the project owner, and who's going to be doing the work?

Josh: I had 4-5 people interested in contributing to the Reference already. But we can expand that if there are interested folks here. For example lcnr is one of the people who rewrote the trait solver. They put the documentation in the rustc trait guide. They'd be perfect for discussing the aspects of the trait solver in the reference and they'd be perfect to move this forward.

TC: Who else?

Josh: Amanieu, Jack Huey, couple of other folks.

Joel: Do we have to have owners for every item in the goal?

Josh: The goal will outline the general areas we plan to address and people interested. But we can add more topics and people if they're interested.

Joel: The goal I wrote in the minutes and the goal you're suggesting seem closely enough that they should combine. Yours would take preference. We can iterate on it onte you have it written up.

Joel: I do agree we probably sholud have a separate FLS goal but I'm not sure what would be in it.

Josh: For the FLS goals it talks about integration of the FLS to the project scope, folks being able to flag what sholud go to the FLS by what time, etc.

Josh: The main item listed on the agenda not in my project goal would be: Ownership, Concurrency etc. I'd be happy to expand the scope to include them to make sure it's comprehensive.

Josh: I could probably get the 0th draft by ?? next week.

TC: Regarding review bandwith: there's interaction between the draw on the reviewer bandwidth and the quality of the PRs we receive. Let's maybe bring the intended authors onto a spec call and set aside time to talk through the practices and standards of the Reference. We want people to send us their Nth draft, not their first draft, just as they would to an editor if they were writing a book.

Josh: That makes a lot of sense. I do think having a "welcome to the reference" kind of meeting to get people accustomed to the idea of what the expected style of the reference is makes sense. We could also use that time to do a live review of the PR. That would help people looking to contribute as well as people who are looking to provide a reference.

Sid Askary: Didn't we have some kind of a glossary last year of what should be in a reference? Do you remember when we talked about what verbiage and what style?

Josh: Are you talking about the meaning of the terminology of "must", "should", "may" etc.?

Eric: I don't remember the discussion, but we don't have anything like that.

Josh: It would be nice if the reference had a Rust glossary and a rough pronunciation guide. "Here's how you pronounce / might hear described common words in the language". E.g. `!` might mean the "never type", and the mapping in the other direction from "never type" to `!`.

Eric + TC: There is a glossary in the Reference.

Josh: Looking at it now, it does serve at least half the function I had in mind. Would still want to add a pronunciation guide.

## "Getting clear improvements merged" Zulip Discussion

[Context](https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Getting.20clear.20improvements.20merged/with/526850479)

Joel: There's a [PR#1725](https://github.com/rust-lang/reference/pull/1725) brought up by Matthew Woodcraft. What should we as a team do about something like this?

TC: The important thing to know, here, which is maybe not immediately apparent in the thread since I'm the one replying, is that it's not that it's not getting merged because of my objection. It's not getting merged because of the standard. This is a shared opinion with Eric and myself. Niko looked at it and he also wanted changes. When lcnr looked at it, he echoed my concerns. The PR author didn't think it was ready. So when someone looks at it and says, "this is an obvious improvement", that's just not the case. That's not obvious at all. There's a lot of work left to do.

TC: Probably what's worth mentioning here is the reason that I replied. We want more people to help us out to improve these kind of PRs. For them to do that, they need to know what the standards are how they can help bring PRs like this up to the standard. My hope in replying was to help people to help us here. And that's what Ralf ended up echoing.

TC: Having written that down is the best possible outcome I see from the thread.

Joel: There doesn't seem to be any policy change that we need to do here, right? This just describes the way we are merging and reviewing things on our side.

TC: We're not going to change the standards on this. We don't want to move sideways. We've got some things in the Reference that are there and are OK. They could be better; they might have flaws and ambiguities. But we don't want to merge something that's five times longer, has a bunch of flaws, is unclear, has nightly stuff in it, etc. That's moving sideways. You don't move a document to where you want to go by moving sideways.

Joel: I initially thought Matthew could break it up and then write a separate PR for the more controversial stuff. There's probably stuff that could be added if it were small.

Josh: Regarding the "it's obvious" mention I had a look at the PR and something with that many lines is not obvious.

TC: @adetaylor did a lot of great work there. But we're not at the bottom of the fact checking and reverse engineering, and a whole lot of editorial work still needs to be done. And when you change it, e.g. to present it with a clearer model, you're going to have to re-check the facts again.

Joel: Is there anything we need to respond to the Zulip thread to close it or do we just leave it?

TC: I think Ralf's response said what needed to be said.

## PR Review

TC: If you look at the PRs page to the reference right now, it's covered by PRs from Eric. He went through every attribute we support, one by one, and put them in a consistent template, filling out missing information. We talked about the template ahead of time and worked out, e.g., what should be presented, what order they should be presented, etc. He spent a ton of time doing this, tens of hours.

TC: When he does this sort of thing, he checks in the compiler source code to confirm the behavior is what he's describing. Then he tests that against the observed behavior of the compiler.

TC: Even with that baseline, it still takes non-trivial time to review these PRs, but it takes far far less than in cases where we can't trust that this has been done. This is the kind of standard we'd like to help other Reference authors hit so as to make our reviews feasible.

## https://github.com/rust-lang/reference/pull/1837
Document how closure capturing interacts with discriminant reads

Eric: Thanks TC. In terms of ones to look at: there's one on discriminant reads on closures. There's a PR (bugfix) how closure captures handle reads on ?? but Nadriel reviewed it already and it seems good already.

TC: We FCPd that on the lang side: https://github.com/rust-lang/rust/pull/138961.

TC: On a first pass this looks really good. I'm happy with the author and I wish that person wrote more Reference PRs. This is a high-quality PR.

TC: There's some small editorial stuff. The bit on slice patterns at the end needs a note about what we're likely to change later. And I'm going to render it and read the whole chapter because that's how you really spot issues.

Eric: I agree with TC. I wrote parts of the chapter. There's an attribute you can past to rustc that lets you know which capture it is. And that's important to understanding the examples. I'd check out the PRs, run the examples through rustc with that attribute and make sure all these are immutable borrows. That's hard to determine by just looking at the source code.

TC: It looks like the underlying PR hasn't merged yet even though our FCP completed awhile back. Probably worth checking in with the author there.

Tomas to follow up with meithecatte and Nadriel and see what they need to get the underlying [PR](https://github.com/rust-lang/rust/pull/138961) merged.

Example of validating capture analysis:

#![feature(stmt_expr_attributes, rustc_attrs)]
#![allow(internal_features)]

fn main() {
    let mut b = false;
    let x = &mut b;
    let mut c =
    #[rustc_capture_analysis]
    || {
        // An ImmBorrow and a MutBorrow of `x`.
        let a = &x;
        *x = true; // `x` captured by UniqueImmBorrow
    };
    // The following line is an error:
    // let y = &x;
    c();
    // However, the following is OK.
    let z = &x;
}

outputs:

error: First Pass analysis includes:
  --> src/main.rs:9:5
   |
9  | /     || {
10 | |         // An ImmBorrow and a MutBorrow of `x`.
11 | |         let a = &x;
12 | |         *x = true; // `x` captured by UniqueImmBorrow
13 | |     };
   | |_____^
   |
note: Capturing x[] -> Immutable
  --> src/main.rs:11:18
   |
11 |         let a = &x;
   |                  ^
note: Capturing x[Deref] -> Mutable
  --> src/main.rs:12:9
   |
12 |         *x = true; // `x` captured by UniqueImmBorrow
   |         ^^

error: Min Capture analysis includes:
  --> src/main.rs:9:5
   |
9  | /     || {
10 | |         // An ImmBorrow and a MutBorrow of `x`.
11 | |         let a = &x;
12 | |         *x = true; // `x` captured by UniqueImmBorrow
13 | |     };
   | |_____^
   |
note: Min Capture x[] -> UniqueImmutable
  --> src/main.rs:11:18
   |
11 |         let a = &x;
   |                  ^ x[] used here
12 |         *x = true; // `x` captured by UniqueImmBorrow
   |         ^^ x[] captured as UniqueImmutable here

## https://github.com/rust-lang/reference/pull/1873

Before the 2018 edition <explanation of pre-2018 behavior>.

> Before the 2018 edition, the behavior was this. As of the 2018 edition, the behavior is that.