rustfmt let-else support

[calebcartwright]

Announce Rustfmt's support for let-else statements

Rendered

I have several objectives that I hope this post achieves:

• Communicating the start of let-else support in Rustfmt
• Attempting to preempt specious assumptions that Rustfmt has "changed" how it formats let-else statements
• Providing context/info around the differences and relationship between the Style Guide and Rustfmt
• Acknowledging the delay in let-else support and providing historical context on some of the relevant circumstances
• Communicating the various efforts, both those completed and those ongoing, to improve things moving forward

Welcome any and all feedback

[joshtriplett]

I think it would be appropriate for us to say something about how we don't, in the future, anticipate adding formatting for an "unformatted" construct like this, but that we're doing so this time because not doing so makes let-else completely prevent rustfmt from doing anything at all.

[calebcartwright]

I think it would be appropriate for us to say something about how we don't, in the future, anticipate adding formatting for an "unformatted" construct like this, but that we're doing so this time because not doing so makes let-else completely prevent rustfmt from doing anything at all.

Agreed, that's a good idea. I will probably opt for softer language though, as there could be another case or two that we need to roll out and I want to avoid this blog post completely ruling out that possibility.

[joshtriplett]

On Tue, Jun 27, 2023 at 09:09:58PM -0700, Caleb Cartwright wrote: > I think it would be appropriate for us to say something about how we don't, in the future, anticipate adding formatting for an "unformatted" construct like this, but that we're doing so _this_ time because _not_ doing so makes let-else completely prevent rustfmt from doing anything at all. Agreed, that's a good idea. I will probably opt for softer language though, as there could be another case or two that we need to roll out and I want to avoid this blog post completely ruling out that possibility.

Sure. My goal here was more to make sure this blog post doesn't imply it's completely OK that we're churning people's (lack of) formatting here.

[calebcartwright]

On Tue, Jun 27, 2023 at 09:09:58PM -0700, Caleb Cartwright wrote: > I think it would be appropriate for us to say something about how we don't, in the future, anticipate adding formatting for an "unformatted" construct like this, but that we're doing so this time because not doing so makes let-else completely prevent rustfmt from doing anything at all. Agreed, that's a good idea. I will probably opt for softer language though, as there could be another case or two that we need to roll out and I want to avoid this blog post completely ruling out that possibility.
Sure. My goal here was more to make sure this blog post doesn't imply it's completely OK that we're churning people's (lack of) formatting here.

@joshtriplett - added some text to cover this in https://github.com/rust-lang/blog.rust-lang.org/blob/895d20f39d3f5e973e1719dc46fc945ad3e9c8bc/posts/2023-07-01-rustfmt-supports-let-else-statements.md#conclusion

[calebcartwright]

It seems like rust-lang/rust#113225 is well on its way to getting landed, which means let-else support should be in the next nightly.

Would be good to get this approved and merged today prior to the next nightly becoming available, if possible, as both t-rustfmt and t-style seem to be 👍 with it

[WaffleLapkin]

rust-lang/rust#113225 is indeed merged, can we proceed here?

[calebcartwright]

rust-lang/rust#113225 is indeed merged, can we proceed here?

I can and will merge if I get an approval, though IIRC that approval needs to come from someone that's part of the leads team based on how branch protections are configured in this repo.

@Manishearth or @ehuss would either of you be willing to 👍 since this is largely a dev tools sub team post?

[Manishearth]

looks great!

[Manishearth]

(can merge, holding off on hitting the button since Caleb indicated he can do it himself and i'm happy to leave the timeline up to him)

[calebcartwright]

Thanks Manish! I'd like to go ahead and get this out, so going to move ahead now

[WaffleLapkin]

I've noticed that the date on the blog is July 1-st, is this expected? I couldn't find any guidelines, is the date supposed to be "written at" date (instead of "publish date")?

[ehuss]

I can and will merge if I get an approval, though IIRC that approval needs to come from someone that's part of the leads team based on how branch protections are configured in this repo.

As for process, on something like this, I normally expect someone from the team the post is about to respond with some form of approval (in this case, someone on the rustfmt or style teams). I didn't see that here, so I can't know if the post represents what the teams want to say.

If a team is sufficiently bottlenecked where that isn't possible (or only has one active person), then proactively reaching out to a lead from the team above you can probably get things merged a little more quickly.

[Manishearth]

@ehuss Caleb is rustfmt lead and Josh is on the style team, so I think this is fine here.

[ehuss]

Yes, but there never was an approval from Josh, or any comment from the other member of rustfmt. I'm not saying that's not fine (or that I don't trust Caleb, I think this post was very well written), I just think in that situation to ping a specific person to merge explaining why will get a faster result. Otherwise, from my observations, the PR will likely sit waiting.

[Manishearth]

Ah, fair, I think they were looking for approval from me as the devtools lead for that, since for the smaller devtools teams this stuff tends to bubble up to me. But yeah, makes sense.