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

Conversion of Uint to Decimal too verbose #2069

Closed
apollo-sturdy opened this issue Mar 25, 2024 · 2 comments · Fixed by #2075
Closed

Conversion of Uint to Decimal too verbose #2069

apollo-sturdy opened this issue Mar 25, 2024 · 2 comments · Fixed by #2075
Milestone

Comments

@apollo-sturdy
Copy link

As mentioned in the below comment:

          How can I convert Uint256 to Decimal256 without being verbose? Right now I need this:

Decimal256::from_atomics(weight,0).map_err(|e| StdError::generic_err("Decimal256RangeExceeded"))?

Originally posted by @FrankBoltzmann in #1186 (comment)

I have two questions here:

  1. Is there a reason not to implement From<DecimalRangeExceeded> for StdError? Doing so would remove the requirement to map the error. If we do this we should also remember to do it for Decimal256RangeExceeded, SignedDecimalRangeExceeded and SignedDecimal256RangeExceeded.
  2. Is there a reason not to simply implement From<Uint128> for Decimal, etc? I assume almost everyone doing these conversions are interested in doing from_atomics(x,0) rather than from_atomics (x,18) so it would be a good choice in my opinion.
@webmaster128
Copy link
Member

Thanks for bringing this up again. I think it got kindof lost for no good reason.

CosmWasm unsigned type conversion (3)

Here is my latest cheat sheet. Turns out there is no good reason other than from_atomics(n, 0) is doing the job. But I agree, there can be a TryFrom implementation doing that. @aumetra could you look into that?

Regarding the error type: no strong reason other than adding everything to StdError got a bit ugly over time.

@webmaster128
Copy link
Member

Part 2. is covered by #2075. I pulled out the error conversion questions (1.) into a separate ticket: #2076

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 a pull request may close this issue.

2 participants