Document let_chains again

[est31]

Mostly a reapply of #1179 which was reverted by #1251. The reapply is not trivial as in the meantime there has been #1561 and #1787, both of which caused merge conflicts. Also add some modifiers.

Tracking issue: rust-lang/rust#53667
Stabilization report: rust-lang/rust#132833

[ehuss]

Some notes about temporaries and drop order:

TC's tests added to rust-lang/rust: https://github.com/rust-lang/rust/pull/133605/files

TC's more up-to-date example playground: https://play.rust-lang.org/?version=nightly&mode=debug&edition=2024&gist=0ce26b5398487e95672adbf389ad946b

Niko's writeup: rust-lang/rust#132833 (comment)

[ehuss]

Scopes

I think the rule in scopes.md labeled names.scopes.pattern-bindings.if-let needs to be updated. My rough understanding is that the scope of an if let binding extends into the following _IfCondition_s and the consequent block.

Edition

At the bottom of if-expr.md, can you add something like:

r[expr.if.edition2024]
> **Edition differences**: Before the 2024 edition, let chains are not supported and only a single _IfCondition_ is allowed in an `if` expression.

I think it makes sense to be at the end of the "Chains of conditions" section? Also just want to double-check the accuracy here.

Destructors and drop scopes

I'd like to see some updates to the destructors page to explain the drop scopes affected by this change. I'm uncertain exactly which changes to make, but I think roughly they are:

• destructors.scope.desugaring -- if let (now just if) can't be directly converted to a match expression, so I don't know how to phrase that.
• destructors.scope.temporary.enclosing -- if let should be rephrased somehow. Perhaps it could be phrased as just if, and somewhere say that multiple _IfCondition_s are translated to the equivalent nested if with single conditions?
  • Or, somehow word it in a similar way to how lazy boolean expressions are worded?
• destructors.scope.temporary.edition2024 -- I'm uncertain if this needs rewording?

[est31]

Thanks for the review. Applied your suggestions and addressed the other review points as well.

if let (now just if) can't be directly converted to a match expression, so I don't know how to phrase that.

When I read that sentence, I thought it's fine, because there is probably a way to express everything with nested match plus break from loops. But it's a bit underspecified, so I made it a little bit more explicit that it's not just a straightforward translation to match.

I made the new sentence suggest the new meaning a bit more clearly, but it's also now stating a bit of a tautology.

• destructors.scope.temporary.edition2024 -- I'm uncertain if this needs rewording?

I think it's fine. One could swap out the if let with some longer wording, but it already feels complicated enough for me, I think.

[ehuss]

@est31 Just checking if you saw the question about names.scopes.pattern-bindings.if-let, where I think the name resolution rules need updating? Is it correct that the bindings are in scope for the following conditions (and consequent)?

Looks like there is also a broken link error in scopes.md.

[est31]

Indeed the bindings are available for all following conditions in the chain (as well as the body). I will adjust the PR.

[traviscross]

This can't be right, e.g. (considering only parsing):

_ = if let () = 0..0 {}; //~ ERROR

That is, the exception isn't just LazyBooleanExpression; it's any boolean expression with a lower precedence than &&.

We're also asking, I think, for something kind of magic to happen here. When we have,

_ = if true == false && let () = () {}; //~ OK

we're hoping for Expression to be true == false. But when we have,

_ = if true || false && let () = () {}; //~ ERROR

we're hoping for Expression to try to be true || false && let () = (), notice that's impossible, and fail (i.e., rather than allowing Expression to be true || false, which would be wrong). But this isn't really encoded anywhere.

Ideas?

[est31]

That is, the exception isn't just LazyBooleanExpression; it's any boolean expression with a lower precedence than &&.

You are right that the exception isn't just that, and maybe it's misleading to list only LazyBooleanExpression because people might think that's an exhaustive list of exceptions.

From what I can see, the reference doesn't require the grammar to be "precedence fitting", i.e. only allow what's possible to express in text form following precedence rules. Instead, it puts the precedence into a table and assumes the grammar is parsed according to the precedence. I would say that table also applies here, as it's part of the larger "expression" family of things.

Because people might think it's exhaustive, we could maybe remove the exception altogether and replace it with a note instead?

we're hoping for Expression to try to be true || false && let () = (), notice that's impossible, and fail (i.e., rather than allowing Expression to be true || false, which would be wrong).

|| has weaker precedence, so there isn't a top level && chain any more. On the other hand, == has stronger precedence.

The example with || is parsed to sth like:

If(
    BinOp(
        ||,
        true,
        BinOp(
            &&,
            false,
            Let((), ()),
        )
    ),
    Block([])
)

The example with == is parsed like:

If(
    BinOp(
        &&,
        true,
        BinOp(
            ==,
            false,
            Let((), ()),
        )
    ),
    Block([])
)

So in the || example, the BinOp with && is actually not top level, its arms can't be IfConditions. So its arms don't have a "permit to let". While in the == example, it has such a permission.

So I think this property is emergent from the grammar and the fact that it is parsed according to precedence.

[ehuss]

IIUC, this will need to be duplicated in loop-expr.md for while loops, too, correct?
(That is, until that restriction is removed.)

[est31]

when I wrote rust-lang/rust#140204 (comment) I thought so too, but there is this paragraph in the while let patterns section:

Multiple condition operands can be separated with &&.
These have the same semantics and restrictions as [if condition chains].

I'd say that this one implies that while let chains are under the same edition specific restriction.