-
Notifications
You must be signed in to change notification settings - Fork 56
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
Is an initial |
on match arms a formatting issue?
#119
Comments
I personally want something like this: rust-lang/rustfmt#2234 . I think it would help a lot with the issue of indenting way too much in Rust. |
👍 to @ubsan's suggestion. This is where Reason landed, for example. Also, I've gotten quite used to the visual nicety of having every pattern in a union type prefaced by a |
It's worth noting that there's a subtle difference: While I can appreciate the reduction of rightward drift, my main worry is that having leading And the problem with the second style (the one without indentation and without leading match self.front() {
None => return None,
Some(e) => {
if e.remove() {
return Some(e);
}
}
} |
I really don't want leading |
Unnecessary |
OK, it sounds like there is consensus that this is a formatting issue, but not on exactly what we should do. IMO, using Therefore I propose we accept option 1, that tools should remove leading |
This adresses issue rust-lang#2621 This commit turns out to be a partial revert of ea3c01e The rationale is that a `|` character preceding a match pattern is not semantically relevant and therefore should be considered a style/formatting choice. A discussion concluded that the best way to emit consistant formatting here was to strip the leading `|` Discussion at rust-lang/style-team#119
This addresses issue rust-lang#2621 This commit turns out to be a partial revert of ea3c01e The rationale is that a `|` character preceding a match pattern is not semantically relevant and therefore should be considered a style/formatting choice. A discussion concluded that the best way to emit consistent formatting here was to strip the leading `|` Discussion at rust-lang/style-team#119
Rustfmt currently uses this formatting: match foo {
Foo::Bar(value)
| Foo::Baz(_ignore_this, value)
| Foo::Quux(_ignore_this, _and_this, value) => {
println!("value = {}", value);
Whatever::One
}
Foo::Spam(value) | Foo::Eggs(_, value) => Whatever::Two(value),
} But the style with leading vert @withoutboats suggested here is starting to grow on me, and looks really neat in this case: match foo {
| Foo::Bar(value)
| Foo::Baz(_ignore_this, value)
| Foo::Quux(_ignore_this, _and_this, value)
=> {
println!("value = {}", value);
Whatever::One
}
| Foo::Spam(value)
| Foo::Eggs(_, value)
=> Whatever::Two(value),
} |
Closed by #127 |
This addresses issue rust-lang#2621 This commit turns out to be a partial revert of ea3c01e The rationale is that a `|` character preceding a match pattern is not semantically relevant and therefore should be considered a style/formatting choice. A discussion concluded that the best way to emit consistent formatting here was to strip the leading `|` This removes the match_with_beginning_vert test because it was asserting the old behaviour which has been changed, it adds a new test (issue_2621) which should be a more comprehensive check of the behavior of `|` in match arms. Discussion at rust-lang/style-team#119
It is now possible in Rust to start a match arm with a
|
, e.g.,Currently Rustfmt treats a leading
|
or not as significant code, i.e., preserves what the user chose to do. However, it is not semantically significant, so one might consider it a style issue, in which case Rustfmt should change it one way or the other (since we believe in consistent formatting, not preserving user input). As a counter-point, we do not strip unnecessary()
although these also are not semantically significant.So, there are three options:
|
|
The text was updated successfully, but these errors were encountered: