Skip to content
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

Create pub constant Decimal::MAX_SCALE #685

Merged
merged 2 commits into from
Oct 15, 2024
Merged

Create pub constant Decimal::MAX_SCALE #685

merged 2 commits into from
Oct 15, 2024

Conversation

Tony-Samuels
Copy link
Collaborator

@Tony-Samuels Tony-Samuels commented Oct 15, 2024

Resolves #684.

Changes are as follows:

  • Change name from MAX_PRECISION to MAX_SCALE, to more accurately reflect what it does
  • Switch (most) docs to refer to Decimal::MAX_SCALE instead of a raw number
  • Switch internal usage to Decimal::MAX_SCALE, mostly just for consistency

@Tony-Samuels Tony-Samuels requested a review from paupino October 15, 2024 14:03
Copy link
Owner

@paupino paupino left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for taking the lead on this. A couple of small suggestions, but overall looks good.

src/decimal.rs Outdated
@@ -523,6 +525,7 @@ impl Decimal {
/// ```
#[must_use]
pub const fn from_parts(lo: u32, mid: u32, hi: u32, negative: bool, scale: u32) -> Decimal {
assert!(scale <= Self::MAX_SCALE, "Scale would exceed maximum support scale");
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess looking back, it would've been nice to new type scale so that it could be validated there. I think if v2 ever materializes it is likely just a breaking clean up of the APIs.

On one hand, I'm with you that "undefined" behavior is breaking anyway - the fact that it was using a remainder I think emphasized the undefined nature of it.
On the other hand, while it was likely incorrect behavior before it didn't panic.

It's extremely difficult to know if downstream systems use this feature incorrectly, however assuming they did and attempting to put myself in their shoes - would I prefer an update to start panicking or continue behaving incorrectly?

That said: I think given the nature of this function (i.e. from raw parts) it is definitely an indication of advanced usage that I think should be fairly rare to utilize so it is probably ok to start asserting. My only suggestion would be a slight tweak:

Suggested change
assert!(scale <= Self::MAX_SCALE, "Scale would exceed maximum support scale");
assert!(scale <= Self::MAX_SCALE, "Scale exceeds maximum supported scale");

src/fuzz.rs Outdated
@@ -8,7 +8,7 @@ impl Arbitrary<'_> for crate::Decimal {
let mid = u32::arbitrary(u)?;
let hi = u32::arbitrary(u)?;
let negative = bool::arbitrary(u)?;
let scale = u32::arbitrary(u)?;
let scale = u32::arbitrary(u)? % Self::MAX_SCALE + 1;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be?

Suggested change
let scale = u32::arbitrary(u)? % Self::MAX_SCALE + 1;
let scale = u32::arbitrary(u)? % (Self::MAX_SCALE + 1);

The only reason I suggest this is so that it includes fuzzing a scale of 0.

src/decimal.rs Outdated
}
};

assert!(
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this is a crate only function I'd perhaps remove this assert. Only because it can sometimes be useful to generate invalid scales etc.

@paupino paupino merged commit 46fb4c3 into master Oct 15, 2024
15 checks passed
@paupino paupino deleted the max_scale branch October 15, 2024 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Expose MAX_PRECISION constant
2 participants