Conversation
We introduce functions such as `int_round_as` as alternatives for every function in the `round_as` family. The new functions use bespoke logic, while the old ones wrap STL functions such as `std::round`. This gives the new functions two advantages: 1. They stay purely in the integer domain. 2. They can support `constexpr`. It feels goofy for an integer input to have to go through floating point, and all of its weirdness at large values. I've never seen anything like this before, probably because the notion of "rounding" an integer type makes little sense in general: it's _already_ an integer. In the realm of unit conversions, though, we do have applications for this. Helps #243. A future PR will add "explicit Rep" versions of these.
| TEST(IntRoundIn, SupportsInt64) { | ||
| constexpr int64_t large_value = 9'000'000'000'000'000'500LL; | ||
| EXPECT_THAT(int_round_in(kilo(meters), meters(large_value)), | ||
| SameTypeAndValue(int64_t{9'000'000'000'000'001LL})); |
There was a problem hiding this comment.
Do we need the int64_t here if we've got LL?
There was a problem hiding this comment.
I didn't think so, until the test failed. Turns out that LL does not necessarily mean "precisely int64_t".
| or need `constexpr` compatibility, consider using [`int_floor_in` and | ||
| `int_floor_as`](#int_floor) instead. | ||
|
|
||
| #### `int_round_in`, `int_round_as` {#int_round} |
There was a problem hiding this comment.
Just looking at how the standard library uses prefixes and suffixes, should the API be int_round_as or round_int_as or round_as_int, or int_round_int_as?
There was a problem hiding this comment.
You forgot int_round_int_as_int. 😅
I wouldn't say I love the name, but I had a hard time coming up with a better one. Really, it's a shorthand for "integer-domain rounding". I wanted to keep the function name as short as I could while still making the distinction.
Now that you bring it up, I think it makes sense to explain this in the docs, so I added a sentence to each section.
Very surprising that this didn't fail before, as apparently this load statement was always needed for bzlmod. It started failing in #637 --- and, interestingly, only on a _second_ commit. Still, the fix is straightforward.
2 participants
We introduce functions such as
int_round_asas alternatives for everyfunction in the
round_asfamily. The new functions use bespoke logic,while the old ones wrap STL functions such as
std::round. This givesthe new functions two advantages:
constexpr.It feels goofy for an integer input to have to go through floating
point, and all of its weirdness at large values.
I've never seen anything like this before, probably because the notion
of "rounding" an integer type makes little sense in general: it's
already an integer. In the realm of unit conversions, though, we do
have applications for this.
Helps #243. A future PR will add "explicit Rep" versions of these.