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 (Non-terminals, e.g. expr, have diverged between parser and macro matcher #86730)
• Stabilization PR (see instructions on forge)

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.

[kristof-mattei]

I am not sure it has been discussed before, and I know it's a syntax which shouldn't be used, but isn't that a bit confusing?

let condition = false;
let some_other_condition = false;

if let false = condition && some_other_condition {
    println!("step 1"); // Does not enter here
}

if let false = (condition && some_other_condition) {
    println!("step 2"); // Enters here
}

The first notation is ambiguous, and maybe not everyone expect the precedence to go that way. At least, there should be some kind of warning, like “You better write it that way: if !condition && some_other_condition { … } if that's what you meant”. That warning may even be shown whenever one pattern matches a bool, regardless of the context.

Correct me if I'm wrong but the way I read the let statement is as follows: does the pattern match? let false = false matches. Just like let None = None. So now we have true && some_other_condition, which is false so we don't enter the if statement.

For the second one we have (false && false), which is false which matches the let false = false predicate.

[mark-i-m]

I think people could reasonably interpret it either way, but it probably auto to be a warning or at least a clippy lint.

[RealRTTV]

Given that without let chains, the only syntactically valid code snippet is the second one, that to not cause breaking changes the only way is to make the first example the correct one?

[PoignardAzur]

Any progress on this feature?

[rami3l]

Any progress on this feature?

@PoignardAzur AFAIK this feature is still blocked on #103476.

A simple ping in this case does nothing. If you'd like to see this feature stabilized, I recommend you to:

try out let chains in your own code, and report bugs you find.

Originally posted by @est31 in #103476 (comment)

[est31]

The main/only blocker at this point that I see is #104843, for which there is #107251, which is blocked on a nice overview comment as asked for in #107251 (comment), then an FCP.

At this point, I don't think that #103476 is a blocker any more, as enough time has passed. For #104893, I think due to the passage of time more people have tried out let chains, at least grep.app shows plenty of users. I don't really think it's much of a blocker either at this point any more.

[pnkfelix]

re todo item "resolve expr fragment specifier issue", see also rust-lang/rfcs#3531, "Macro matcher fragment specifiers edition policy".

[photino]

This feature is really helpful. Is it possible to use in the Edition 2024?

[slanterns]

It's not related to edition.

[inquisitivecrystal]

This feature is really helpful. Is it possible to use in the Edition 2024?

Hi!

No, I'm afraid not. Editions have to do with changes that might break old code; as far as I know, this is completely unrelated. Also, people generally prefer that this sort of question not be asked on the tracking issue, as it sends a notification out to everyone subscribed to the thread without providing new information. It's no big deal, just something to be careful about going forward.

I believe the current status is described in est31's last post above.

[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!

[Nilstrieb]

@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.