-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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.
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
style-guide: Clarify let-else further #113139
Conversation
Give some additional examples with multi-line patterns. Make it clearer to go on to the next case if the conditions aren't met.
r? @yaahc (rustbot has picked a reviewer for you, use r? to override) |
Some changes occurred in src/doc/style-guide cc @rust-lang/style |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This update and the examples give us the cover we need on the rustfmt side so feel free to r=me, though one inline thought left below on a potential element of clarity
If the initializer expression is multi-line, the `else` keyword and opening | ||
brace of the block (i.e. `else {`) should be put on the same line as the end of | ||
the initializer expression, with a space between them, if all the following are | ||
true: | ||
the initializer expression, with a space between them, if and only if all the | ||
following are true: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I feel like the ambiguity comes from the fact that this all starts with the "if the initializer expression is multi-line" up on line 160, as that could be read as meaning the text that follows is not applicable if the expr itself is single line.
I'll think on some additional text proposals, but wanted to go ahead and share that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's true, but in the single-line case it doesn't matter if you try to apply these rules or not; the three conditions can't possibly hold for a single-line initializer. You can't have a single-line initializer expression that consists of nothing but closing parentheses, square brackets, and/or braces.
So, whether you look at this case and go "doesn't apply because it's not multi-line" or look at this case and go "doesn't apply because the conditions don't hold", either way you go on to the next case.
@bors r=calebcartwright rollup Going to go ahead and merge this with Caleb's r+; we can still make further text improvements as they arise. |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#112670 (privacy: Type privacy lints fixes and cleanups) - rust-lang#112929 (Test that we require implementing trait items whose bounds don't hold in the current impl) - rust-lang#113054 (Make `rustc_on_unimplemented` std-agnostic) - rust-lang#113137 (don't suggest `move` for borrows that aren't closures) - rust-lang#113139 (style-guide: Clarify let-else further) - rust-lang#113140 (style-guide: Add an example of formatting a multi-line attribute) - rust-lang#113143 (style-guide: Narrow guidance about references and dereferencing) r? `@ghost` `@rustbot` modify labels: rollup
Give some additional examples with multi-line patterns.
Make it clearer to go on to the next case if the conditions aren't met.