-
Notifications
You must be signed in to change notification settings - Fork 449
Forbid usage of some complex Option:: methods. #5754
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
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -1519,10 +1519,8 @@ impl ExtractTimestampRange<'_> { | |
// a match_none, but the visitor doesn't allow mutation. | ||
lower_bound = lower_bound.saturating_add(1); | ||
} | ||
self.start_timestamp = Some( | ||
self.start_timestamp | ||
.map_or(lower_bound, |current| current.max(lower_bound)), | ||
); | ||
|
||
self.start_timestamp = self.start_timestamp.max(Some(lower_bound)); | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. i know this is correct, but i find relying on Ord of Option to not be something easy to read. If we're moving away from map_or (which i don't think we should ban), i prefer the more verbose "min" variant line 1540, or even better, a rational: to me, this operation is "take the larger of the values, or lower_bound if start_timestamp is unset", and this is how the code used to read. With just max, you need some thinking to make sure this is correct, and there isn't really a human sentence to describe what it does. With There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If we're optimizing for self.start_timestamp_opt = if let Some(start_timestamp) = start_timestamp_opt {
Some(start_timestamp.max(lower_bound))
} else {
Some(lower_bound)
} |
||
} | ||
|
||
fn update_end_timestamp(&mut self, upper_bound: &quickwit_query::JsonLiteral, included: bool) { | ||
|
@@ -1537,10 +1535,9 @@ impl ExtractTimestampRange<'_> { | |
// a match_none, but the visitor doesn't allow mutation. | ||
upper_bound = upper_bound.saturating_add(1); | ||
} | ||
self.end_timestamp = Some( | ||
self.end_timestamp | ||
.map_or(upper_bound, |current| current.min(upper_bound)), | ||
); | ||
|
||
let new_end_timestamp = self.end_timestamp.unwrap_or(upper_bound).min(upper_bound); | ||
self.end_timestamp = Some(new_end_timestamp); | ||
} | ||
} | ||
|
||
|
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 don't agree with this list (except probably for xor). i generally like functional-style operation chaining. Can other people weight in on what we should do? cc @guilload
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 don't think we should vote on this issue, because
the U.S.western democracies show us that it does not work. Sorry, I'm feeling cheeky this morning.I also generally like functional-style operation chaining, so I'm biased. However, I do agree that Rust is taking it too far sometimes.
I also don't think we should take this issue too seriously because once the conversation is about personal taste and preference, it's hard to have a productive exchange.
Generally, I'm fine with allowing none of the functional constructs, some of them, or all of them. In the first case, it might make the code more readable for some people. In the second, we try to strike a balance and code might be more enjoyable to write for people like Trinity and me. Finally, in the third case, it's just beneficial for Paul's brain plasticity ;)
As main contributors of Quickwit, I invite you two to have a face to face call to find a middle ground that works for both of you.
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.
For me they are all hard to read except
is_some_and
.Generally
map
+unwrap_or
is very readable to me (and also kinda standardized)I think this is should not be about personal taste, but readability, e.g.
is_some_and
is readable to me, but I don't like it.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.
okay, so let's replace
.map_or()
and its variants with.map().unwrap_or()
then