T-style triage meeting 2025-06-18

--- title: T-style triage meeting 2025-06-18 tags: ["T-style", "triage-meeting", "minutes"] date: 2025-06-18 discussion: https://rust-lang.zulipchat.com/#narrow/channel/346005-t-style/topic/meeting.202025-06-18/ url: https://hackmd.io/Rg7_6BzOSDC82MA7m6V3pQ --- # T-style meeting agenda - Meeting date: 2025-06-18 ## Attendance - People: Caleb, Josh, TC, Tomas ## Meeting roles - Driver: TC - Minutes: Thomas ## 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 ### "Chains style and the `await` keyword" style-team#166 **Link:** https://github.com/rust-lang/style-team/issues/166 Josh: Additionally this would come up in the case when you want to break multiple lines in the chain. One chunk of the chain may have multiple arguments, then closing the paren followed by `.await?`. But broadly in favour treating `.await` the same way we treat `?`. TC: I'm aligned on that. In the language it's essentially the same as the question mark. It'd be interesting to see the result of a big code base adjusted with this change. Caleb: I don't have strong opinions. We don't have any complexity driven metrics. That means there's a significant difference in terms of the amount of columns `.await` will take compared to `?`. Are we OK with cases where some `.await` calls will wrap, and some won't? Josh: That is a case where we should consider whether to treat .await differently than ?. Right now we treat ? as inseparable from the closing paren attached to it. Should we treat .await like ? where if you have to wrap .await you must wrap the thing it's attached to (`).await?;`)? Or should we ever say that it's only the `await` that needs wrapping (`.await?;`)? Are we ever willing to separate from what it's attached to? TC: I'd be interested to see a codebase that would treat it as inseparable. I hypothesise that it'd actually look better. Interested in validating that by seeing it. Josh: I agree. Don't have a preliminary guess of which ones looks better. I expect that treating `.await` as attached to the closing paren will result in having more function calls in a chain turned into multi-line constructs, but that might be OK. TC: In particular, it avoids an issue of being inconsistent in a chain if it's always treated as atomic. Josh: One potential issue: wouldn't be surprised if some folks experienced the wrapping we today as a mechanism that highlights `.await` in a chain and so it's easy. And if you put it on the same line, it might be less obvious where it is? But that should mainly be mittigated by lints. The only case would be a type that's useful on its own but also implements IntoFuture. I've seen this in async form of a connection. Sometimes the way you send it is to do `.await` on the connection and await the response. ### Edition process for T-style / rustfmt Caleb: On the rustfmt side: we do have ability to make a code change on a feature branch and test that on any repository that's publicly available and do a diff. So for any codebase taht's able to execute `rustfmt` or `cargo fmt` directly we can do that. Caleb: If there are possibilities of certain contexts/audiences, maybe we could do a configuration option. Let people opt-into it. If we find we like what we see, we can change the default to what we want but leave the toggle in place. TC: This came up somewhere else in Rust 2024. We ended up reverting something we planned to stabilize with the style edition. And one of the reasons was there wasn't a configuration control. Caleb: I'll maintain the position for rustfmt that we're willing to do that where it makes sense. We have made a large change without a configuration option. I don't think having an option should be a default operating mode and how it helps with the testing process. TC: Aside from rustfmt, the procedure we're working is: it's got to be under a rustc feature flag first. We don't just add stuff to the edition. We add it to the "future edition" and eveerything has an individual feature flag. Only when we stabilize a feature on a particular numbered edition do we remove the feature flag and put it in a numbered edition. Is there a way we could do something like that for rustfmt so the changes can be tested and evaluated separately? Caleb: The model we have today is: someone using nightly rustfmt has the ability to opt-in to the non-default (v-next) style edition. That could be things we're definitely sure and also things that we're just considering. I think what you're saying is: instead of having a single style edition, we'd have an option for every style option. TC: Yes, that would align better with how we do editions. Caleb: It's not that it's impossible to do. But this would increase burden on rustfmt and it's a very stretched team. One of the most stretched teams in the project. This doesn't seem like it'd help rustfmt. Not clear how this helps the style team, how it helps improve the style edition or how to get it ready. Josh: Procedurally, it isn't within the scope of the style team to be determining anything other than the default style. So this doesn't seem like a style conversation. TC: Regarding the value, from an edition side, in the last edition, people ended up rather confused with what was happening with rustfmt/T-style due to these process differences. In fact, we ourselves ended up rather confused, in that we were trying to work out in a number of cases what had been added to the style edition and whether those things had actually been approved by the style team. Cleaning up the process here I think would help us as much as anyone. --- TC: Separately from that. The other thing I'd suggest is that I do think there's some value to the team in style editions mostly being about flipping defaults. If rustfmt, for its own reasons, added a flag for people to change this or that, and we're seeing that it looks better and people like it, then that flag seems like a good candidate for turning it to a default. And that reduces our risk as we're just setting as a default something that's previously been used by a lot of people. Caleb: I don't think it's a controversial observation that getting enough people to test anything on nightly across the project. If we have enough issue getting people test the one option -- what's make us think that having more option would increase people testing and providing feedback earlier in the process? TC: I'm not interested in adopting the new style edition on any code I'm sharing with people if it's all WIP. But if we do have an option that we've felt comfortable enough to stabilized (again, on its own merits) -- or even maybe one that's unstable (but again, stood on its own merits with the rustfmt team for that) -- that provides a single unit of value and is more easily adopted. For any stable ones, they could show up in the Rust changelog, and people could be turned onto them in that way. Caleb: rustfmt is not included in Rust release publications. None of our changes are in the public release notes. TC: We should fix that. Caleb: rustc hase been using the nightly style edition. And minimising churn is something we take very seriously. Caleb: rustfmt having to stabilise an option means our stability guarantees ??. Once something is stable, we have no ability to change that, remove it, change it. That's not something we can support. Josh: +1 to everything Caleb said. One advantage of the style edition is you have to support everything in the style edition together. That might get lost for individual options. Adding an option is convenient for people wanting to opt in for that one thing. Josh: TC, you brought up that the nightly style edition is not something you'd do in a public project. Yes, that's not what it's for! What you'd do is: try it out, see what happens, give feedback, then revert it and go back. Just like you'd do for unstable features in rustc. TC: My purpose here is what we adopt as style policy and how we constrain ourself. It's not to put any burden on rustfmt; I'm not suggesting they do anything differently. I'm saying that in many situations it would be good if we could constraint ourselves to things that have shown value and passed the bar that rustfmt imposes for their own purposes. We might, e.g, prioritize consideration of things in which rustfmt has already found value. TC: Making big changes over style editions carries far more risk when the individual items haven't had any chance to prove themselves out separately. Caleb: If we're constraining ourselves to what's already in rustfmt vs. Style wanting to come up with something new -- I understood that part of waht you were saying. And I think that's a reasonable thing to do. TC: There was the entire separate discussion on style edition policy. Then there's this piece, where I'm discussing how making large style edition changes without a way to separately prove out the pieces is a bit unsettling. I'm suggesting more conservatism not less. Josh: Appreciate the clarification, I didn't pick up on that. Josh: Generally speaking I push back on just doing things that we have stable (or unstable) options for. TC: (This is not a proposal, let's set aside the resource constraint -- which is very real and we should work on -- and just speak hypothetically.) If we had some change we wanted to make -- something we think would be an improvement. And we're sure about it -- so sure we'd stabilize it with a style edition. What I would say is that same level of certainty would imply a level of certainty for putting it into stable rustfmt as an option. Caleb: To clarify: are you suggesting that we'd provide a stable option as a means of providing this to the community even before the edition? Or to provide this so people can deviate and do something different? TC: Here's what we do on the lang side a lot. We have something we don't like. We start stabilizing things that go in the direction we want. We start stabilizing lints. We've introduce the new thing but allow the old, and over the edition we flipped the switch; we change the default. To your question, if we have some change we're so confident in that we want to introduce it in a style edition, then in a well-resourced world we might provide a separate option to use it before it landing in a style edition. That then has the effect of letting people adopt our improvements incrementally, and it lowers the cost for those people to then adopt the style edition. Josh: To some extent, one of the reasons we put features in every edition is less about people being able to use them without upgrading. It's more to do help the maintenance of the compiler. If the feature is able to work across editions, it's easier to put it and maintain it in the compiler. If we did that in rustfmt, we can't do that due to the backwards compatibility guarantee. And if we do this as an option, it could increase the complexity of rustfmt. Caleb: Would you typically expect for the option to be removed once it's turned on by default once it's in the new edition. Rust having a style guide with the default is leaning towards having more consistency and have Rust code look more similar. The degree the style can provide more options is a consideration. And having an option does carry more maintenance burden. It makes it more difficult to add new options -- bugs when particular options are set. TC: I take for granted that rustfmt has already crossed a bridge of being more configurable. At some point it has made the decision that it's not going to be a `gofmt`. Caleb: The way I've articulated this to users is: I don't this has to be 0 or 1 or unlimited. The fact that you offer 1 doesn't mean you have to add everything and anything. We have to apply some level of discretion. If we'd implemented an option of e.g. selecitng the sorting algorithm -- that'd be a lot of work to do that. And to this date there has been no one who asked for this. Caleb: But if there's something we feer strongly as something that's unequivocally that this is better -- is there an audience that needs this to be turned off independently? I don't like the means of people trying to persuade me that since we have some options, we need to add this particular option. TC: Yes, nobody (here) is defending adding any old option. ### How to increase capacity of rustfmt team Josh: I want to highlight how little capacity the rust format team has -- is there some strategy or way to help with getting more recruitement for that team? TC: Great question, very interested in that. Caleb: Looking at history: the Cargo team put a call out. I'm open to anything that helps that situation. There have been a couple of people that tried to help in the past and were frustrated about the stability, things taking long, the gating. ### Helping make rustfmt more sustainable TC: How are things going on the rustfmt side? Caleb: It's just the two of us. He's had some life stuff going on. I don't really get to code any more. Outside of small bug fixes there's not a lot happening. TC: How can the project help? What could the project do in your wildest imagination? Caleb: I think individuals well-versed in the project -- familiar with Rust's syntax tree -- are able to pick up things much more quickly. We need people who are interested or willing. I don't know anyone who's deeply passionate to work on the formatter. I think there are people willing to help, but they're also on other teams that may be more passionate for that. If the projcet were able to put a call out there to bring individuals who would be willing to help. Or someone passionate about formatting. We need folks to write code, review code. TC: Is there any world in which we could get the people on the compiler team more interested? Is there maybe some way to bring rustfmt closer to the compiler team? Those are the people who have all the necessary knowledge. It seems odd we have such a large group on this side and such a small group on the other. Caleb: There used to be some folks who popped over. But they expressed an interest in being able to help. But the interest faded quickly. And the compiler work would get more attention and energy. TC: I feel like that's our target market -- getting the people on the compiler team. Maybe people take it for granted or think you guys don't want the help. Maybe we could put a blog post on inside-rust. Maybe if people started putting 20% of their time on rustfmt that might add up. Caleb: Recognition and visibility might be motivating. Maybe even getting the rustfmt release notes into the rust project. A lot of projects put contributors in their release notes. Caleb: If someone came in ready to help reviewing PRs, they might not even know where to start (there's lot of stale PRs). In my experience having 1-1 conversations is working much better than e.g. having labels. TC: Here's a concrete thing we can do as a takeaway here. Let's put out an inside-rust blog post. We'll lay it out. Everyone uses rustfmt, but it's supported by a very small team. Bring up things we'd like to do if we had capacity. Talk about what you could use help with, and talk about the ways you're willing to help people help you, e.g. in terms of having time for one on ones with people. Etc. Tomas can carry the load there of getting that together. Tomas: Happy to help. Caleb: I like the sound of that, would need to brainstorm a bit. Tomas: I'll put together some ideas here and run them by you, Caleb. ### "`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 ### "Styling of Rust Frontmatter" style-team#212 **Link:** https://github.com/rust-lang/style-team/issues/212 ### "Formatting for cfg_match" style-team#201 **Link:** https://github.com/rust-lang/style-team/issues/201 ### "Review of nightly style process" style-team#202 **Link:** https://github.com/rust-lang/style-team/issues/202 ### "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 ## Pending PRs on the style-team repo None. ## RFCs waiting to be merged None. ## `S-waiting-on-team` None. ## Proposed FCPs **Check your boxes!** ### "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 ### "Formatting for cfg_match" 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 ## P-critical issues None. ## Check-out (Not minuted.)