T-spec meeting 2025-01-09

--- title: T-spec meeting 2025-01-09 tags: ["T-spec", "meeting", "minutes"] date: 2025-01-09 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202025-01-09 url: https://hackmd.io/NR0zNaOMQhixBrq0LIa4mA --- Attendees: Joel Marcey, Mara Bos, Connor Horman, TC, Pierre-Emmanuel Patry, Eric Huss, Niko Matsakis Regrets: Agenda - Reference Rule Readability - Trying Operational Work in the Meeting - Timeline for integrating FLS ## Reference Rule Readability https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Rule.20readability.20in.20the.20reference PR has been created by Waffle: https://github.com/rust-lang/reference/pull/1710 Still needs to be reviewed. TC: We may need a followup PR to fix id wrapping, etc. ## Trying Operational Work From the last meeting... > TC: It can be hard to cut off a topic because finishing it and disposing of the matter can be on net more efficient than having to pick it back up later and essentially repeat much of the same discussion. > > Niko: There's that, and also I've realized that talking through these items is how we calibrate as a team and build a shared understanding and shared values. Maybe only half of the discussions are important for this, but it can be hard to tell in the moment whether or not a particular item is in this category. > > TC: Yes. That's also become apparent to me in doing Reference reviews with Eric. We've become far more calibrated and synchronized by doing those. And so, similarly here, I wonder whether there might be value in using the time on the spec calls to do operational work -- like lang does in triage -- to go through review items. There's essentially an infinite amount of this work to do, and beyond getting the work done, it will also help us to calibrate as a team. > > Niko/ehuss/Joel: +1. > > All: Sounds like a plan for the new year TC: Pull up reference PRs and see what is tagged and then go from there. Connor: Easy GitHub search query unless there is something specific to be discussed. Joel: GitHub source of truth for now. Start the process and see what needs to be tweaked. Eric: Some of these PRs have overlap with lang. How do we deal with that for now? Niko: Role of this group is slightly more than editorial. Try to give lang more directions than just read the PR, but instead say things we want the lang team's input on. TC: https://github.com/rust-lang/reference/pull/1693. Requires stabilization on the lang side. In this case the diffs were all correct but when we read the chapter as a whole it turns out that the surrounding text talked about "code in the asm block" and it became unclear what code it was referring to (i.e. the assembly code or the code that is now included as part of the labels). Niko: I wonder about having a designated reviewer whose role is to prepare thoughts question more thoroughly for others to consume. This has come up in other contexts. Eric: Discussions happening in the lang calls where some t-spec is not involved, and vice-versa. How do we deal with that lack of overlap? Niko: Would `t-spec` ever feel empowered to merge a PR without consulting `t-lang`? Maybe yes. Eric: Maybe some of `t-spec` needs to be content experts in things we are not - e.g. assembly -- so that we can be conversational with experts on the lang team. Joel: When does the time that we actually decide to bring in the lang team actually happen? TC: As we review the PRs we will know. Niko: We may make mistakes, but that is ok. TC: https://github.com/rust-lang/reference/pull/1707. What do we want a PR like this to look like. Part of a stablization request to lang, etc. What should the expectations be? We will build alignment by talking it through. Niko: What do you think about that PR, TC? Would not be effective to kick it to the lang team to do research. It would be up to `t-spec` or the PR author. Connor: PR seems to have more information than any other target. Niko: Sometimes the lang team may not be any more qualified than the spec team, and then we would push work back on the PR author. TC: https://github.com/rust-lang/reference/pull/1226 is another example. What is `t-spec` team role with a PR like this? Eric: One of the challenging things on the PR was negotiating with the lang team on what we want to document. Panics are huge. What degree do we want to document it. Niko: That PR is a good one. The right outcome is to request a deep read from a lang team expert. TC: There is a lot of text in 1226 that refers to C++, but is not deep linked to a specific place in the C++ standard. Eric: Can we bug lang advisors if we have questions on a topic, specifically Alex on 1226? Niko: It is important to have a subject matter expert to find subtle things and overall experts to understand the entireity of a topic. Niko: In the case of the C++ question raised, the intention is to match the behavior of what C++ does Joel: How does timing work when we require lang team or subject matter experts to review things? Eric: When it is nominated, then things get queued. TC helps manage the queue :) Joel: Do we have staging areas for items that `t-spec` thinks are good, but we want verification? Niko: How do we handle nightlies? TC: In an ideal world, of course we'd want to handle it like the compiler, with a feature flag. Unfortunately it's harder to conditionalize English than Rust. There are hard tooling and organization questions there. Niko: Would love if spec was tool to record decisions. TC: https://github.com/rust-lang/reference/pull/1622. Something that we are waiting on `t-lang`. (Discussion.) TC: And yet another one: https://github.com/rust-lang/reference/pull/1689. Is there anything on the spec team side that we want to queue up before the lang team looks at it? (Discussion.) ## Timeline for Integrating FLS https://rust-lang.github.io/rust-project-goals/2025h1/spec-fls-integration.html Joel: Goal is to have spec integrated by June 30, 2025 as per H12025 project goal :). Hopefully before then. Current status is that Foundation and Ferrous legal teams planning to meet. Should have clarity on that meeting next week. Connor: Need new owner of subgoal to review FLS tooling. Joel: I can own it. ## Chat TC TC says: https://github.com/rust-lang/reference/pull/1693 8:11 avatar Connor Horman Connor Horman says:Lending Credence to my Institution Model, where the Spec Team has the judicial role over the Rust Language. 8:18 avatar Niko Matsakis Niko Matsakis says:I'm not sure if I see it as *judicial*, I actually think that might be more lang's role 8:19 Niko Matsakis says:maybe european judicial 8:19 avatar Connor Horman Connor Horman says:No, lang is legislative - they decide *what* the language should be. 8:19 Connor Horman says:(And then spec parses out what that means and how to express it) 8:20 avatar Niko Matsakis Niko Matsakis says:that is true: I guess judicial if you ignore the reality in the US. 8:20 T TC TC says: https://github.com/rust-lang/reference/pull/1707 8:21 avatar Niko Matsakis Niko Matsakis says:(Connor, what I meant is that I don't think the spec team should be deciding "between interpretations" -- more like, if there's ambiguity, throw it to another team to specify.) 8:21 T TC TC says: https://github.com/rust-lang/reference/pull/1226 8:26 Niko Matsakis Niko Matsakis says:actually the RFC *may* have been good enough, I remember BatmanAod put quite some work into that 8:33 avatar Connor Horman Connor Horman says:project-ffi-unwind would have made many of the decisions, but I don't believe there are any formal record of the decisions. 8:33 avatar Niko Matsakis Niko Matsakis says: https://rust-lang.github.io/rfcs/2945-c-unwind-abi.html 8:34 LANG MOVES AT ITS OWN PACE 8:38 Niko Matsakis says:WE WILL NOT BE RUSHED 😂 8:38 T TC TC says: https://github.com/rust-lang/reference/pull/1622 8:43 https://github.com/rust-lang/reference/pull/1689 8:46