T-style triage meeting 2025-12-03

--- title: T-style triage meeting 2025-12-03 tags: ["T-style", "triage-meeting", "minutes"] date: 2025-12-03 discussion: https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/Meeting.202025-12-03/ url: https://hackmd.io/19XMGTpdQuGFCN7jz7G7Ig --- # T-style meeting agenda - Meeting date: 2025-12-03 ## Attendance - People: Josh, Caleb, TC, Tomas ## Meeting roles - Facilitator: TC - Minutes: Tomas ## Check-in (Not minuted.) ## Scheduled design meetings None. Update these [here](https://github.com/orgs/rust-lang/projects/38/views/1). ## Proposed design meetings None. Update these [here](https://github.com/orgs/rust-lang/projects/38/views/1). ## Announcements or custom items (Meeting attendees, feel free to add items here!) ## Nominated RFCs, PRs, and issues ### "add rustfmt support for `cfg_select`" rust#144323 **Link:** https://github.com/rust-lang/rust/pull/144323 TC: Manish spun up the rustfmt-contributors team. Are they helping? What's the status there? Folkertdev has expressed pessimism about the rustfmt side moving: https://github.com/rust-lang/rust/issues/115585#issuecomment-3591892736 > I'd be in favor of FCP: there is a large upside for the ecosystem and I don't see the rustfmt stuff moving unfortunately. Caleb: I'm surprised by that. I've not had any time for open source stuff for the path month or so. The last thing I communicated was cfg_select and front matter as the priorities. I thought there was a PR with implementation for cfg_select Josh: Folkert put together a patch to add rustfmt support for cfg_select. It mostly worked, had issues around rules that use comma. He's happy to iterate but could use help from someone familiar with the guts of rustfmt. Caleb: I'll try to redirect folks to look at this. I hope folks haven't been getting too lost in refactorings, config options etc. My stance is that rustfmt should follow the style guide. Caleb: There was something we stabilized, added support for rustfmt afterwards because we didn't want rustfmt to block the stabilization. TC: Are you talking about let-else? We stabilized it for furstfmt support, the Style team didn't exist and that caused consternation. Caleb: That may have been it. Caleb: We're talking macros instead of pure Rust syntax. Those are a little bit different. I think this would be the first case of having a stabilization gated on style rules. We don't have heavy style prescriptions on macro calls. Josh: It seems there are 2 levels of handling macros. (1) actually formatting them for which we don't have a lot of style prescription. But (2) we want to format the insides of them as Rust code. TC: Do we have any other stdlib macros where the argument to the macro is a Rust body? Josh: Any of the `assert!` macros you can provide an arbitrary Rust expression. ANd those can be arbitrary brace blocks. Caleb: We also have cases like `matches!`. TC: Let me rephrase. Do we have any other macros where the argument is expected to be a multiline body commonly with items in it? Josh: in the commen case rather than just permitted? Josh: It's not uncommon to see arbitrary things in `println!`. But I'm not aware of any macros where the standard ordinary usecase is a brace block that will have multiple lines in it. TC: I think this macro is kind of unique that the common use case here will be arbitrary multi-line Rust code. Caleb: `cfg_if!` is an example from the ecosystem where a lot of multiline Rust looking code where people requested formatting. TC: Caleb what do you think about stabilizing this on lang side without style support? Caleb: My concern would be people who would be upset if a feature would be blocked. ANd there are people who would be upset that a feature was stabilised without rustfmt. We did go through a lot of up cycles when proposing the change to the stabilization process to incorporate the style rules being present. And there was a lot of pushback. And it was for this reason: people anticipating this situation would recur (considering bandwidth). The lang team made the decision -- they could decide to gate on Style rules and gate on rustfmt implementation. That wasn't the decision made. Caleb: So for lang, my vote would be: if it's ready to stabilize it, stabilize it. If you want to change the policy to wait on us, that's fine too. But I think the situational response should match the policy. TC: For context, often the arrow points the other way: our policy reflect what our practice is. So we update the policy based on our situational decision. The situational matters gives us a lot of colour and texture to evaluate the decision. Josh: I had not realised the policy was to be style but not rustfmt. I had the impression of the work on style editions, that we had in practice been blocking on formatting support. TC: I recall you being familiar with this in the past. Maybe it's just out of cache for you. Josh: Right, the difference hasn't surfaced that much recently. Caleb: TC, I'm +1 on pragmatism over dogmatism. I'm not suggesting the policy be followed strictly for the sake of policy. It's more that this seemed to be something the lang team wanted to do intentionally. When rustfmt was utilising the rustc autopublish crates, we were regularly very behind what syntax was supported by the compiler. There were times where rustfmt was actually crashing on newer Rust syntax. The target state is good: being able to format the Rust code of the macro. It's a big difference from the way things were not that long ago. Caleb: I still have reservations on things being gated on rustfmt. TC: I don't consider it hard gated on rustfmt. If we ask around and the answer is "this just isn't going to land any side too" then, ok, let's stabilize it. But it's worth us asking the question in the context of there being this new energy around rustfmt-contributors. If it is plausible soon, that does change the calculus. From the lang side I'm interested to hear what you'll find in terms of being able to redirect the contributors etc. Caleb: I like the philosophy of it being a judgement call informed on the context of the particular situation. That is reassuring. ### Growing the team Caleb: I'm still in the same unfortunate position of I really don't know how to grow the team. We did create some documents, policy procedures back in the day. Not sure that's something we want to tee up to revisit. Does that still make sense in the context of recruiting work and considering team members. TC: I think we're not even to the point since we don't have any viable candidates. The way all the team selection works across the Project is people showing up and doing the work. And the fact no one else is here is the problem. TC: I'm hopeful the same sort of energy around the rustfmt side -- some percentage of them may be interested in Style. Maybe people may be interested for other reasons -- e.g. doing interesting things such as cfg_select. We could make a bit of noise about putting up blog posts about doing what we're doing. Josh: I agree the way we evaluate people for being able to consider is align with the ??. It would be worth doing a refresher on looking at the guidelines we have for people to help us think of people who may be good candidates? Josh: And we could also see where do we want to look when we're looking for people. We know that rustfmt are recruiting people and people show up and we don't know how that's happening. But we could maybe see if the people coming there might be interested in the Style. And the other is doing a Project-wide call. Caleb: Agreed across the board. I mentioned looking at whatever we put together. It's public, on github in the Style repository. Maybe someone takes looks at it and it may be more restrictive than what we'd do today and maybe they'd self-deselect themself from even stopping by. And I'll be on the look out on the rustfmt. TC: The other option is to shut down the Style team and reabsorb it into Lang. Maybe there aren't that many decisions that we need to decide. Josh: Like the Lang team needs more bikeshed. TC: Yes, we're at capacity. But because we're at capacity, people present us stuff, make a decision and push it back to them. If we were to reabsorb this to the lang team, we'd do this by necessity. The proposers would have to propose style rules, express them clearly so the lang team could understand them and have this be part of the FCP. TC: There's a sense in which the language features are related to formatting. Sometimes people want a language feature just because it's going to format more nicely. Caleb: When we were forming a team, there was a lot of consideration on where this should be and we ended up benig a subteam of Lang for that reason. At least in some cases how syntax is going to be written and read is consideration. But it's also not just net-new syntax. There's consideration of existing features, or someone deciding that we need to have tabs instead of spaces etc. And in those cases the line starts to get a little muddy. My hope would be that the Style team can exist to handle the things that Lang doesn't care about while also able to take direction as the parent team. Josh: Given that the current direction we need in Lang is more delegation, it's worth noting what the null option. But I feel we need to evaluate prospective folks in order to make the team healthier. But in that regard it's worth considering ways in which we change the sytle in which we're operating. Josh: Right now when we're considering a feature coming along we propose how it should be formatting. It would make sense for us to ask people proposing features to add a first draft of expected formatting. TC: To build on your point, that's worth seeing -- for the people in their RFCs to specify the formatting proposal in it. And why not push that early enough in the process. In the same way as I want to see the diff to the Reference text. Josh: Any time we make a change earlier in the process, we need to be aware of the filter that can this cause. We have to evaluate the impact of frontloading the work. TC: There's a balance. TC: In a queing system, backpressure (for all its faults) works better than random drops. TC: In terms of viable candidates, the back stop of membership is we have to drag lang members into the style team. Josh: That sounds like a microcosm of creating a process hazard we don't want to do. If we have a small team that's putting more process for the team that they may not desire. TC: In any organisational context where you have an attention hierarchy, you have to do backpressure down this hierarchy tree. This how Linus is able to run the Linux process -- being the only person who merges stuff having a group of trusted people who send him patches. There are only so many ways it can work. ### "Add style guide for default field values" rust#149423 **Link:** https://github.com/rust-lang/rust/pull/149423 ### "Chains style and the `await` keyword" style-team#166 **Link:** https://github.com/rust-lang/style-team/issues/166 ### "`edition.md` is causing many conflicts" style-team#192 **Link:** https://github.com/rust-lang/style-team/issues/192 ### "Style Guide prescriptions on ABI explicitness" style-team#199 **Link:** https://github.com/rust-lang/style-team/issues/199 ### "Formatting of associated types with GATs very verbose" style-team#200 **Link:** https://github.com/rust-lang/style-team/issues/200 ### "Formatting for cfg_select" style-team#201 **Link:** https://github.com/rust-lang/style-team/issues/201 ### "Never break between empty parens" style-team#210 **Link:** https://github.com/rust-lang/style-team/issues/210 ### "Improvements to match formatting" style-team#211 **Link:** https://github.com/rust-lang/style-team/issues/211 ### "let else with multi-line else-block, always put else in new-line" style-team#214 **Link:** https://github.com/rust-lang/style-team/issues/214 ## Pending PRs on the style-team repo None. ## RFCs waiting to be merged None. ## `S-waiting-on-team` None. ## Proposed FCPs **Check your boxes!** ### "Stabilize Frontmatter" rust#148051 **Link:** https://github.com/rust-lang/rust/pull/148051 ### "style-guide: Note that we don't account for comments in every possible place" rust#121762 **Link:** https://github.com/rust-lang/rust/pull/121762 ### "Improvements to match formatting" style-team#211 **Link:** https://github.com/rust-lang/style-team/issues/211 ## Active FCPs ### "Never break between empty parens" style-team#210 **Link:** https://github.com/rust-lang/style-team/issues/210 ## P-critical issues None. ## Check-out (Not minuted.)