T-spec meeting 2025-07-17

--- title: T-spec meeting 2025-07-17 tags: ["T-spec", "meeting", "minutes"] date: 2025-07-17 discussion: https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Meeting.202025-07-17/ url: https://hackmd.io/NvYTqewkREe3ynJcCStLfg --- Meeting URL: https://meet.jit.si/rust-t-spec Attendees: - Joel Marcey - tshepang - Sid Askary - Eric Huss - TC - Josh Triplett - Jack Huey Regrets: - Tomas Sedovic - Niko Notes: Joel Marcey Agenda: - Updates to the agenda? - 2025H2 Rust Project Goal Review: @JoelMarcey - 2025H2 Rust Project Goal Followup: @joshtriplett - PR Review: @TC0 @ehuss ## Updates to the agenda No updates ## 2025H2 Rust Project Goal Review 2025H2 Project Goal Proposal: Develop the capabilities to keep the FLS up to date - [PR](https://github.com/rust-lang/rust-project-goals/pull/335) - [Rendered Proposal](https://github.com/JoelMarcey/rust-project-goals/blob/fls-up-to-date-capabilities/src/2025h2/FLS-up-to-date-capabilities.md) - Premise: Now that that FLS is an official part of the Rust Project and we can publish the FLS independently of dependencies required in the past, let's see if we can develop the capabilities to keep the FLS up-to-date with Rust language additions and changes. Thank you ehuss and TC for their feedback and suggestions. Josh: Have the impression that Ferrous is going to continue updates... Eric/TC: tshepang has been making updates. Will that continue? tshepang: Yes, will continue until a process is in place that allows Ferrous to stop making contributions. TC: This goal, along with other discussions, brings to mind that we might want to consider putting together a plan for how we could achieve a defining description of the language in a fixed period of time, e.g. 2 years, given sufficient resources, and to seek those resources. We're not going to add another project goal here, of course. Joel: Would love to see that happen. I could put out feelers. Josh: There is nothing stopping us from making more progress on trying to find more resources without having a Project goal. Instead, let's make a plan to try to make this happen. TC: This topic has also be raised, by others, in the context of the Foundation's upcoming three-year strategy. There are two necessary things for a plan that would deliver a specification of the quality we'd want and with high assurance of success. One is being able to hire exactly the right people to do it, and the other is having the resources necessary to support those people. In terms of how many people are needed here, it needs to be more than one. No plan that involves hiring only one person can give our stakeholders high assurance on this kind of timeline. People get sick, have kids, etc. And people underestimate how long things will take. There has to be some "excess capacity" (i.e. capacity that will seem excess at the start, but will turn out not to be) for the plan to be sure to work. In my estimation, a research team of three (highly-qualified) people would be the minimum that would make me comfortable with giving assurances. Five would be better. ## 2025H2 Rust Project Goal Followup After the discussion last week, @joshtriplett's Reference-based Project Goal has been [proposed](https://github.com/rust-lang/rust-project-goals/pull/336). Any followup discussion required? TC: Question about one-way-door bullet point. Eric: The intent of the reference is to be prescriptive of what Rust is. We have made language guarantees in the Reference, and the intent is to continue in that direction. Sid: What is the ground truth, the document, the spec team, the lang team? TC: The lang team holds the ground truth. But there is a balance with the prior precedent of what the lang team has said. Josh: Want to avoid the outcome of being hung on determining what is correct as opposed to writing it down. Sid: Would it be possible to have the start of the reference state what guarantees it is presenting? Josh: Failure mode is, blocking some contribution to the reference that accurately describes how Rust *currently* behaves, because we wish it behaved differently and/or want to discuss what behavior it *should* have. TC: Let's iterate on the language: * When writing down descriptions of Rust based on the observed current behavior of `rustc`, we sometimes encounter areas where we're not entirely sure whether we want to guarantee the observed behavior as the behavior of Rust. There are two cases: 1. We're unhappy with the current behavior of some edge cases. Here, we will prefer to document the current user-visible behavior while leaving an "admonition" (a non-normative note, warning, disclaimer, etc. in the Reference) that there are open question about whether we may wish to change this behavior. 2. We're uncertain about whether the behavior represents a guarantee or simply one of many behaviors that Rust could validly exhibit. Here, we will document the current behavior in an "admonition" while noting specifically that this does not represent a language guarantee and that other behaviors are possible. TC: (After the meeting, in discussion with Josh, we later adopted a variation of and various extensions to this.) ## PR Review ## Jitsi Chat Josh Josh says:👍 8:26 T TC TC says: https://github.com/rust-lang/leadership-council/issues/197 8:42 Sid Askary Sid Askary says:Josh, can you post the link here? 8:45 J Josh Josh says:👍 8:46 Josh says: https://github.com/rust-lang/rust-project-goals/pull/336 8:46 me says:Actually, I withdraw my comment. It doesn't really matter at this point. I think the two project goals we have are the right ones given the *current* landscape. 👍 8:47 Josh Josh says:(Short version of my response: I think if we hired people, we'd *add* them to this plan, not *replace* the people who are part of this plan.) 8:48