Skip to content

style guide: add let-chain rules #139456

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Apr 7, 2025
+72 −6
Merged

style guide: add let-chain rules #139456

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 72 additions & 6 deletions src/doc/style-guide/src/expressions.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -521,8 +521,11 @@ self.pre_comment.as_ref().map_or(

## Control flow expressions

This section covers `if`, `if let`, `loop`, `while`, `while let`, and `for`
expressions.
This section covers `for` and `loop` expressions, as well as `if` and `while`
expressions with their sub-expression variants. This includes those with a
single `let` sub-expression (i.e. `if let` and `while let`)
as well as "let-chains": those with one or more `let` sub-expressions and
one or more bool-type conditions (i.e. `if a && let Some(b) = c`).

Put the keyword, any initial clauses, and the opening brace of the block all on
a single line, if they fit. Apply the usual rules for [block
Expand All @@ -548,10 +551,11 @@ if let ... {
}
```

If the control line needs to be broken, prefer to break before the `=` in `*
let` expressions and before `in` in a `for` expression; block-indent the
following line. If the control line is broken for any reason, put the opening
brace on its own line, not indented. Examples:
If the control line needs to be broken, then prefer breaking after the `=` for any
`let` sub-expression in an `if` or `while` expression that does not fit,
and before `in` in a `for` expression; the following line should be block indented.
If the control line is broken for any reason, then the opening brace should be on its
own line and not indented. Examples:

```rust
while let Some(foo)
Expand All @@ -572,6 +576,68 @@ if a_long_expression
{
...
}

if let Some(a) = b
&& another_long_expression
&& a_third_long_expression
{
// ...
}

if let Some(relatively_long_thing)
= a_long_expression
&& another_long_expression
&& a_third_long_expression
{
// ...
}

if some_expr
&& another_long_expression
&& let Some(relatively_long_thing) =
a_long_long_long_long_long_long_really_reallllllllllyyyyyyy_long_expression
Comment on lines +597 to +598
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't the = be on the second line here, given the explanation above of "prefer to break before the ="?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good catch

I think the "before operator" prescription may have been a snippet of text we missed in #113145 (and some more context linked in rust-lang/style-team#179) when we changed the text to match the existing behavior of always breaking after the operator

for example, rustfmt has long formatted chainless if let Some(....) .... with breaks after = - https://play.rust-lang.org/?version=stable&mode=debug&edition=2024&gist=9f656a763b2b09c559d39568c2d5079c

fn main() {
    if let Some(x) = a_long_long_long_long_long_long_really_realllyyyy_long_expressionddddddddddddddddd {
        // ..
    }

    if let Some(relatively_long_thing) =
    a_long_long_long_long_long_long_really_realllyyyy_long_expression
{
        // ..
    }
}

is formatted as:

fn main() {
    if let Some(x) =
        a_long_long_long_long_long_long_really_realllyyyy_long_expressionddddddddddddddddd
    {
        // ..
    }

    if let Some(relatively_long_thing) =
        a_long_long_long_long_long_long_really_realllyyyy_long_expression
    {
        // ..
    }
}

I'm going to change the text in the control flow section to indicate breaking after under the same rationale as we had previously of "bug fix" to the style guide text, but happy to discuss more if you think that's the wrong direction

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good call. I agree that we should match the existing behavior.

&& a_third_long_expression
{
// ...
}
```

A let-chain control line is allowed to be formatted on a single line provided
it only consists of two clauses, with the first, left-hand side operand being a literal or an
`ident` (which can optionally be preceded by any number of unary prefix operators),
and the second, right-hand side operand being a single-line `let` clause. Otherwise,
the control line must be broken and formatted according to the above rules. For example:

```rust
if a && let Some(b) = foo() {
// ...
}

if true && let Some(b) = foo() {
// ...
}

let operator = if !from_hir_call && let Some(p) = parent {
// ...
};

if let Some(b) = foo()
&& a
{
// ..
}

if foo()
&& let Some(b) = bar
{
// ...
}

if gen_pos != GenericArgPosition::Type
&& let Some(b) = gen_args.bindings.first()
{
// ..
}
```

Where the initial clause spans multiple lines and ends with one or more closing
Expand Down
Loading