-
Notifications
You must be signed in to change notification settings - Fork 105
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
Make opaque Scalar
conversions explicit rather than using From
/Into
trait.
#228
Labels
Comments
/bounty $100 |
💎 $100 bounty • Space and TimeSteps to solve:
Thank you for contributing to spaceandtimelabs/sxt-proof-of-sql! Add a bounty • Share on socials
|
This was referenced Oct 7, 2024
Closed
JayWhite2357
added
enhancement
New feature or request
good first issue
Good for newcomers
refactor
Code cleanup or reorganization
and removed
enhancement
New feature or request
labels
Oct 8, 2024
/attempt #228
|
/attempt #228 Options |
💡 @maujim submitted a pull request that claims the bounty. You can visit your bounty board to reward. |
@JayWhite2357 can you please take a look at the liked PR? |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
Background and Motivation
Currently, the
Scalar
trait requires various conversions using theFrom
andInto
traits. Some of these are confusing, while others are clear.In general, the rule should be that for types with a natural embedding into the associated
Scalar
field,Scalar
should implementFrom
. In all other cases, the conversion should either be auto-implemented, or a trait method, where appropriate.NOTE: The following issue also necessitates changes to Scalar, so be aware of potential merge conflicts:
#234
Changes Required
Each of these should be a separate PR.
Into<[u64; 4]>
,From<[u64; 4]>
, andRefInto<[u64; 4]>
bounds.fn from_limbs(val: [u64; 4]) -> Self
andfn to_limbs(&self) -> [u64; 4]
Scalar
is a field element (number mod some prime) with slightly less than 256 bits. Usually,Scalar
s are internally stored in Montgomery form, so these conversions are non-free. However, they are needed in some situations.From<&'a String>
,From<String>
, andFrom<&'a str>
bounds. These three implementations ultimately rely on the conversions to and from limbs. As a result, these should have blanket/default implementations.fn from_str_via_hash(val: &str) -> Self
and add a default implementation.impl<S: Scalar> From<String> for S
, this is not allowed by the Rust type system. Solutions other than the default implementation of a trait method are welcome.Scalar
itself. This is different from a parsing method.VarInt
bound and replace it with a blanketimpl<S: Scalar> VarInt for S
implementation. The existing (and requested) implementation relies on the limb conversions only.The text was updated successfully, but these errors were encountered: