Tracking issue for eRFC 2497, "if- and while-let-chains, take 2"

[Centril]

This is a tracking issue for the eRFC "if- and while-let-chains, take 2" (rust-lang/rfcs#2497).
For the tracking issue for the immediate edition changes, see #53668.

Steps:

• Implement the RFC (cc @rust-lang/compiler -- can anyone write up mentoring instructions?)
• Adjust documentation (see instructions on forge)
• Formatting for new syntax has been added to the Style Guide (nightly-style-procedure)
• resolve expr fragment specifier issue (#86730)
• Initial stabilization PR: Stabilize let_chains in Rust 1.64 #94927, reverted in Revert let_chains stabilization #100538
• Second stabilization PR: Stabilize let chains in the 2024 edition #132833

Unresolved questions:

• The final syntax
  • This would benefit from a design note summarizing previous discussions on let as a boolean expression, and possibilities of is syntax.
• Should temporary and irrefutable lets without patterns be allowed in some form?
• Chained if lets inside match arms

Collected issues:

• unused_parens incorrectly lints on if let true = (false && true) {} #60336
• Cleanup hack to expect scrutinee: bool in if-to-match desugaring in match-expr typeck #60707
• Deduplicate diagnostics in if-without-else-as-fn-expr.rs #60254
• MIR building for match $c { true => $i, _ => $e } is slow #60571
• Suggest if let when a failed if block could be parsed as one #44990

Implementation history:

• Run branch cleanup after copy prop #59290
• Generalize diagnostic for x = y where bool is the expected type #59439
• Introduce hir::ExprKind::Use and employ in for loop desugaring. #60225
• [let_chains, 1/6] Remove hir::ExprKind::If #59288
• [let_chains, 2/6] Introduce Let(..) in AST, remove IfLet + WhileLet and parse let chains #60861
• [let_chains, 3/6] And then there was only Loop #61988
• Reintroduce hir::ExprKind::If #79328
• Introduce hir::ExprKind::Let - Take 2 #80357
• Lower condition of if expression before it's "then" block #82308
• Formally implement let chains #88642
• Add tests to ensure that let_chains works with if_let_guard #93086
• Fix let_chains and if_let_guard feature flags #93213
• [rustc_parse] Forbid lets in certain places #97295
• Warn users about || in let chain expressions #94754
• Ensure that let_else does not interact with let_chains #94974
• [let_chains] Forbid let inside parentheses #95008
• Tell users that || operators are not currently supported in let chain expressions #95314

Unresolved problems

• Can we be confident that the implementation is correct and well tested?

[Centril]

I'm working on implementing this in a 3+ PR step fashion based on discussions with @oli-obk.

[oli-obk]

for the record, the discussed step list is

1. remove if from HIR and make lowering emit a match
2. remove if let from AST and instead have a let expression
3. "do the rest of the work" (might get split up further).

[alexreg]

I can't imagine 3 would be a particularly large step (enough to merit splitting), but 3 steps sounds fair enough.

[estk]

@Centril I'm really jazzed about this feature, lmk if there is any work I can help with.

[sammysheep]

Nightly user here. My experience with this feature has been very good. I'm surprised with how concisely I can convey my intent.

I find I tend to use chains with 3 clauses for some reason, and the succinct transitive nature of it feels elegant.

10/10. Would recommend!

[Noratrieb]

@joshtriplett has opened rust-lang/rfcs#3573 and it is not clear whether it makes sense to have both features (I personally don't think so).
If it was decided that this should be stabilized (either because the RFC is rejected or because the lang team would like to have both), then it would need someone familiar with the let chains implementation to confirm that they are confident the implementation is correct now.

[est31]

Yeah before we stabilize this we should in any case wait for the decision on that RFC, which in this instance can turn in any direction.

[roylaurie]

Yeah before we stabilize this we should in any case wait for the decision on that RFC, which in this instance can turn in any direction.

I think this should keep moving forward. Why trash all of this work unless the other RFC actually gets accepted?

The other idea has already been shot down before. The recent sentiment I've seen on Reddit and in the comments on Github don't paint a picture of anything changing in that regard.

[jpmckinney]

I also say keep moving forward. In terms of governance, I don’t think it makes sense to pause work on one RFC anytime another RFC suggests an alternative. That’ll just stall everything. (Also, that other RFC will not pause for this one.)

[TennyZhuang]

I do not think rust-lang/rfcs#3573 should block this RFC. is operator is an alternative to the existing feature if let, but not let-chains. The motivation of the new is operator is better readability from a left-to-right style, which means that it should also replace existing if let Some(x) = y to if y is Some(x). Regardless of whether the is operator is a more reasonable expression, we cannot remove the existing if let style, so extending it is still meaningful.

[CEbbinghaus]

After reading rust-lang/rfcs#3573 I actually disagree with @TennyZhuang. The two features stand in opposition to one another as they both offer the same functionality. However the is operator is significantly more flexible and consistent due to it returning a boolean which lets it fit anywhere a boolean can. Currently the only thing that cannot be achieved any other way is chaining pattern matching which this RFC addresses. As such if this RFC makes it to stable then there is 0 functional reason to add is, only ergonomic reasons (which already has a vocal opposition).

[Noratrieb]

Please remember that tracking issues are not for discussion, but for updates, especially large ones like this one. Please open a new issue/Zulip/internals.rust-lang.org thread (that can be linked from here) to discuss the feature, so that people subscribed to the issue don't get spammed and the issue history remains readable.
I want to avoid locking the issue so that people can post links to discussion.

[traviscross]

We talked about this in the lang planning meeting today. As far as we know, the blockers and semi-blockers to this have been resolved. E.g.:

• Tracking Issue for updating expr macro fragment specifier for Rust 2024 #123742
• Tracking Issue for Rust 2024: Rescope temporary lifetimes with respect to else #124085

At this point, we would encourage someone to write up a comprehensive stabilization report and include that in a PR proposing let-chains for stabilization. We're looking forward to considering that proposal.

[est31]

This is really wonderful news, @traviscross! I've went over the original stabilization PR (now reverted) and related issues to refresh my memory. I've found two possible stabilization blockers that I have opened zulip threads about.

• syntactic rejection is maybe not complete?
• formatting stabilization: from how I read this document, nightly syntax formatting needs to be stabilized and formalized. We have formatting present in rustfmt but is it also formalized?
• I don't see anything that should be a stabilization blocker with the F-let_chains label at this point

As there is many people subscribed, please try to keep replies in the linked zulip threads.

[est31]

Stabilization report/PR: #132833