if let pre-stabilization preview

[Kivooeo]

This was moved to https://internals.rust-lang.org/t/pre-stabilization-if-let-guards/22901

r? @est31

[est31]

I'd expect exhaustiveness checks to work like with normal guards: they don't play into exhaustiveness checks at all.

[est31]

I think we should take the approach that we adopt 2024 drop order behaviour on all editions. As it's a green field new feature, we can do that. Because I see that there is edition differences on the example from #104843 adapted to if let guards: there is a broken MIR ICE on 2021, but no ICE on 2024. Edit: had a look again, now it seems to not reproduce any more???

When it comes to #103476 (comment) , I can't reproduce it on the 2021 edition.

[est31]

I'd also check if the lints for bindings properly visit if let guards: they are a new concept, so maybe not all lints are adapted to them. E.g. do we check for irrefutable tails via the irrefutable_let_patterns lint (see #94951 for the work I did on let chains)? Irrefutable suffixes need to be allowed though as there is no easy way to write those (due to the match making things conditional).

[est31]

Also, from experience from let chains and let else we should really ensure that we get the drop order right. I think if let guards are a bit more rarely to be used than former two features, so users won't be doing as much experimentation with it. On the other hand, having done both let chains and let else gave us some experience around drop order which we can apply to if let guards as well (tests in the testsuite as a minimum).

As a procedural note, even though I have responded, PRs adding documents are generally not the place the Rust community has discussions. Either one can discuss it in https://internals.rust-lang.org/ or on zulip. But it's also fine to file a stabilization PR right away, at the cost that it might be open for years :).

[Kivooeo]

@est31 Thanks! I actually have quite a bit of free time right now, so I’ll spend it digging into this further. Also, I completely forgot about the internals forum — you’re right, it would probably be a better place to post my write-up, maybe with a Gist link to the full review

My original thinking was to open a PR just to get some feedback on the general state of the feature, and then either close it or follow it up with a proper stabilization PR

I’ll check whether the lints behave correctly later today

One thing I’m wondering about: how can I enable the 2024 edition drop order behavior in older editions?

Maybe it would make sense to rename the current PR to something like “pre-stabilization review” and add a checklist of steps toward stabilization? Would that be a reasonable approach?

[est31]

add a checklist of steps toward stabilization?

I personally love checklists, they allow organizing things really well. With github checklists though, especially in PRs or issues, people have an expectation that you keep them up to date. So I'd suggest making one but making it clear that it's not the "real" one, just a draft for the actual stabilization report.

One thing I’m wondering about: how can I enable the 2024 edition drop order behavior in older editions?

I suppose you can take a look how the 2024 drop order was introduced. It should be possible to adjust that code to support special treatment for if-let guards. The most relevant reading in that regard is these two PRs:

• https://github.com/rust-lang/rust/pull/107251/files
• https://github.com/rust-lang/rust/pull/131984/files

[Kivooeo]

@est31 I'm wondering if we should enable if let guards only for edition 2024 and later. I tried removing the edition checks and applying the IfLetRescope behavior in edition 2021, but it led to MIR issues (e.g., internal compiler errors related to drop scopes). Given that let_chains were also stabilized only for edition 2024 to avoid similar backward compatibility pitfalls, maybe it makes sense to take the same approach here? We could open an issue later if compatibility between editions becomes essential, but for now, it seems reasonable to restrict this feature to edition 2024. After all, it is stable (at least in 2024 edition), and thanks to if let rescope, it is now highly predictable and stable, especially for things like move and drop semantics

I guess if we can start from stabilizing it in 2024 edition only, then I think it's a good point to open stabilization PR from

[Kivooeo]

irrefutable_let_patterns
Also, works as intented, will try to check other lints today, maybe will found something
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=8accdf1497ec546de7be072b832b6de0

[est31]

It might be that the errors you mentionhave an easy fix. In any case, as I've said before, let's discuss this in a github issue, an internals.rust-lang.org thread, or a zulip thread.

Oh and before I forget it, rustfmt support is quite important too. It needs to be tracked for stabilization.

[rust-log-analyzer]

The job mingw-check failed! Check out the build log: (web) (plain)

Click to see the possible cause of the failure (guessed by this bot)

# RECOMMENDATIONS

* Fix missing copyright/licensing information: For one or more files, the tool
  cannot find copyright and/or licensing information. You typically do this by
  adding 'SPDX-FileCopyrightText' and 'SPDX-License-Identifier' tags to each
  file. The tutorial explains additional ways to do this:
  <https://reuse.software/tutorial/>

  local time: Sun May 11 11:52:09 UTC 2025
  network time: Sun, 11 May 2025 11:52:09 GMT
##[error]Process completed with exit code 1.
Post job cleanup.

[Jules-Bertholet]

an internals.rust-lang.org thread

https://internals.rust-lang.org/t/pre-stabilization-if-let-guards/22901