style-guide: Rewrite let-else section for clarity, without changing formatting #112912
Conversation
…ormatting The section as written did not cover all cases, and left some of them implicit. Rewrite it to systematically cover all cases. Place examples immediately following the corresponding case. In the process, reorder to move the simplest cases first: start with single-line and add progressively more line breaks. This does not change the meaning of the section at all, and in particular does not change the defined style for let-else statements.
joshtriplett
added
the
T-style
|
(rustbot has picked a reviewer for you, use r? to override) |
rustbot
added
the
S-waiting-on-review
|
Some changes occurred in src/doc/style-guide cc @rust-lang/style |
| If a let statement contains an `else` component, also known as a let-else statement, | ||
| then the `else` component should be formatted according to the same rules as the `else` block | ||
| in [control flow expressions (i.e. if-else, and if-let-else expressions)](./expressions.md#control-flow-expressions). | ||
| Apply the same formatting rules to the components preceding | ||
| the `else` block (i.e. the `let pattern: Type = initializer_expr ...` portion) | ||
| as described [above](#let-statements) |
There was a problem hiding this comment.
I forget where, but I know there's been some recent discussion around trying to encapsulate certain prescriptions in one place to avoid duplication, and I'd add, the potential for accidental drift (e.g. breaks around the assignment operator).
I completely agree with that goal, and while it's likely best punted to 2024 edition work, I feel like the basics of "how to write an else" block are something we could capture in one place and then reuse (e.g. the else keyword must be followed by a space before the opening brace, if multilined then the closing brace must be preceded by a break, etc.)
Then any syntax specific context can respectively specify where the else keyword should start, and any unique wrapping rules
|
Given this is tantamount to an internal word refactoring with no "external" changes (i.e. I 100% agree this doesn't change the formatting rules) I'm just going to go ahead and approve as it doesn't seem like an FCP is warranted. @bors r+ rollup |
bors
added
S-waiting-on-bors
…ications, r=calebcartwright style-guide: Rewrite let-else section for clarity, without changing formatting The section as written did not cover all cases, and left some of them implicit. Rewrite it to systematically cover all cases. Place examples immediately following the corresponding case. In the process, reorder to move the simplest cases first: start with single-line and add progressively more line breaks. This does not change the meaning of the section at all, and in particular does not change the defined style for let-else statements.
…llaumeGomez Rollup of 8 pull requests Successful merges: - rust-lang#112703 ([-Ztrait-solver=next, mir-typeck] instantiate hidden types in the root universe) - rust-lang#112854 (fix: add cfg diagnostic for unresolved import error) - rust-lang#112912 (style-guide: Rewrite let-else section for clarity, without changing formatting) - rust-lang#112915 (Update runtests.py : grammar correction) - rust-lang#112971 (issue template: add clippy entry which points to the clippy repo) - rust-lang#112989 (Add a regression test for rust-lang#109141) - rust-lang#113002 (bootstrap: Backup `settings.json` to the correct filename) - rust-lang#113003 (Fix old python deprecation check in x.py) r? `@ghost` `@rustbot` modify labels: rollup
The section as written did not cover all cases, and left some of them
implicit. Rewrite it to systematically cover all cases. Place examples
immediately following the corresponding case.
In the process, reorder to move the simplest cases first: start with
single-line and add progressively more line breaks.
This does not change the meaning of the section at all, and in
particular does not change the defined style for let-else statements.