Simplify kernel AND/OR logic #110
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Merged
roeap
approved these changes
Jan 29, 2024
Comment on lines
-290
to
+307
| fn mul(self, rhs: Expression) -> Self::Output { | ||
| fn mul(self, rhs: Expression) -> Self { |
There was a problem hiding this comment.
this is of course equivalent and less verbose. personally i have a slight preference for the more verbose syntax to favour consistency over brevity.
on the other hand this shows more clearly that is produces the same type ...
There was a problem hiding this comment.
Yes, I went through the same questions and ultimately decided that type Output = Self makes clear enough that we're returning the same type, and that Output is only needed to satisfy the trait. Does that sound reasonable?
nicklan
approved these changes
Jan 29, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The variadic AND/OR code was more complex than it needed to be. We can simplify by allowing them to be empty, with well-defined default values (
AND() == TRUEandOR() == FALSE), and also by defining staticxx_frommethods for building up lists.While we're at it, replace most uses of
Expr::binaryandExpr::variadicwith direct convenience methods.NOTE: In the spirit of "don't optimize" this PR intentionally does not optimize the various degenerate cases that can arise. These include, but are not limited to (OR cases are similar):
There are probably others as well. Rather than (try to) implement all of those optimizations, or guess which subset of optimizations is "most valuable", we choose to not implement any of them for now.