T-spec meeting 2024-10-24

--- title: T-spec meeting 2024-10-24 tags: ["T-spec", "meeting", "minutes"] date: 2024-10-24 discussion: https://rust-lang.zulipchat.com/#narrow/stream/399173-t-spec/topic/Meeting.202024-10-24 url: https://hackmd.io/i8z5CqmGQzKmjnlZ7XL71A --- Attendees: Joel Marcey, Eric Huss, (pnk)Felix, TC, Connor Horman, Mara, Pierre-Emmanuel Patry, Niko Matsakis, Monadic Cat Regrets: Agenda: * FLS/Reference/Spec Discussion Revisited * [Standard Library Normative Definitions](https://rust-lang.zulipchat.com/#narrow/channel/399173-t-spec/topic/Normative.20definition.20of.20.60core.60). * [reference#1662](https://github.com/rust-lang/reference/pull/1662) * ehuss: Process improvements. * There is a challenge with asking people who want to stabilize something to also be responsible for authoring documentation for it. They may not be familiar with the style, quality, voice, or thoroughness we expect. They also may not be particularly strong with technical writing. What feasible options do we have to improve that? We can expect the spec team to be responsible for writing most (all?) new content. But then there is a gap (chasm) between someone saying they want to stabilize something, and someone on the spec team having the time and knowledge to write it down. The spec team can work cooperatively with the proposer to get all the details, but it is challenging. We've talked about coordinating that in some way with the stabilization report they are expected to write, but that has its own challenges (it has been difficult to get sufficient information from that to write the reference material). What is a better way to structure this? ## FLS Discussion Revisited Niko: Short version is that we are consildating on a plan that we adopt the FLS as the Rust Language specification and work to merge with the Reference. Niko: Unresolved question on where that goes and still digging. Adopting the FLS as-is and giving it some sort blessing is an important step to take. This would be useful for those creating qualified toolchains. We take on some obligation to keep it up-to-date. Niko: Migrate gradually. There are some unknowns - burden to take on updating it from release to release, etc. But we can work through that. Niko: Creating an RFC to propose the plan moving forward. https://hackmd.io/3_YmQDnUQAWpT88lv2zLmQ?view Mara: One of the reasons initially to not adopt the FLS was because there is a lot of errors. Huge undertaking to fix. What is the plan to audit what is already there? Niko: Yes, we need to audit and vet the FLS. Mara: If we adopt the FLS as it was designed for (safety critical / certification), then that's ok. If we adopt it for implementing a compiler or working on RFCs something, then there will be a lot of work to get it there. Niko: Document the process to get the FLS with less errors in the RFC. Connor: What resources do we have to audit the FLS? Joel: Working at the Foundation to try to get resources assuming we go down this route. Niko: Resources are key; but, we need to decide on the directional change here first (assuming we had infinite resources) pnkfelix: Agree with Mara in principle. The thing that has changed is customers are betting on the FLS. So we should take a chance on the Project owning the FLS to make sure those customers are not left out to a spec that is not Project owned. Niko: Good point from Felix. Bring the FLS in slowly. Reference is still key. Mara: We should bring the FLS into the project. But what do we do with it when that happens? Connor: Is there a line where the money and resources becomes too much for us and the customer? Joel: Resources will be front-loaded until we get to a steady state. pnkfelx: Connor's hypothetical may be true, customers can't give us feedback on cost. Sid: Didn't Ferrocene say they would be providing us resources? Joel: Conflicting information Niko: Believes that is possible, assuming a credible plan. Joel: Recalls that resources may have been available from Ferrocene to help bring the spec into the Project. Niko: Three steps. 1. Transition the spec into the Project. 2. Maintainence from release to release with new content (1-2 days of work). 3. Merging the document with the Reference TC: It's worth thinking about what it means exactly to adopt the FLS into the project. We can look for analogies here in how we treat projects like rust-analyzer. It's distributed by the project, but it's not tier-1 in the same sense that typeck is. If your PR affects typeck, you need to address that in the same PR. It's blocking. But if your PR affects r-a, it's not blocking, and the r-a folks will notice and handle the r-a changes later, themselves. At least at the start, the FLS will be more like r-a than like typeck. Niko: Reference is the normative document in some sense. We need to get the primary specification into a form that works within our processes. General agreement that we move forward with this plan. Niko to propose the RFC. ## Stdlib Discussion https://github.com/rust-lang/reference/pull/1662 Connor: Should we be documeting the stdlib normatively into the specification - whether that is the Reference or the FLS? Eric: Why is this not in the core documentation? Can we just fix it that the code sample is just showing what platform it is for or just not show it all? Connor: That would be up to folks working on rustdoc. TC: Does the FLS cover the stdlib at all? Connor: Doesn't yet. TC: Many specifications cover the stdlib of the language. It's a reasonable thing to want, but for us it would be a lot of ground to cover. Niko: There is stdlib, core and then the core of core. Focusing the spec on the core of core. Things that you can't desscribe the language rules without. Connor: Should we do this in some capacity? And is the PR sample the correct way to do it? Eric: We don't have the manpower to keep things in sync. Niko: Narrow scope down to lang items, starting with one or two. There might be some value in duplication, potentially. ## Process Improvements ### Context There is a challenge with asking people who want to stabilize something to also be responsible for authoring documentation for it. They may not be familiar with the style, quality, voice, or thoroughness we expect. They also may not be particularly strong with technical writing. What feasible options do we have to improve that? We can expect the spec team to be responsible for writing most (all?) new content. But then there is a gap (chasm) between someone saying they want to stabilize something, and someone on the spec team having the time and knowledge to write it down. The spec team can work cooperatively with the proposer to get all the details, but it is challenging. We've talked about coordinating that in some way with the stabilization report they are expected to write, but that has its own challenges (it has been difficult to get sufficient information from that to write the reference material). What is a better way to structure this? ### Discussion Eric: There are in general improvements we can make. A lot of this lies on `t-lang` on how they want to approach the stabilization. Eric: Updating documentation to coincide with changes has been a challenge. Niko: We should not rule out hiring people to do this. Maybe the `t-spec` team could be re-arranged to focus on this. Joel: Probably need to see if we can get more people on the `t-spec` team to help, even if we re-arrange.