-
Notifications
You must be signed in to change notification settings - Fork 198
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
Why is NonZeroScalar::invert()
fallible?
#499
Comments
The issue is It would probably make sense to get that Unfortunately this would require a breaking change to the |
Or perhaps we could have |
Because `NonZeroScalar` means we'll never divide by 0, it's possible to make the implementation infallible. To accomplish this, `CtOption` is removed from the `Invert` trait's signature, and used as the result type for scalars that are potentially zero as part of the blanket impl of `Invert`. Fixes RustCrypto/elliptic-curves#499
Because `NonZeroScalar` means we'll never divide by 0, it's possible to make the implementation infallible. To accomplish this, `CtOption` is removed from the `Invert` trait's signature, and used as the result type for scalars that are potentially zero as part of the blanket impl of `Invert`. Fixes RustCrypto/elliptic-curves#499
Because `NonZeroScalar` means we'll never divide by 0, it's possible to make the implementation infallible. To accomplish this, `CtOption` is removed from the `Invert` trait's signature, and used as the result type for scalars that are potentially zero as part of the blanket impl of `Invert`. Fixes RustCrypto/elliptic-curves#499
RustCrypto/traits#894 implemented the proposed changes:
|
It feels like, since we know that it is nonzero, there should be some
fn invert(&self) -> NonZeroScalar
, or at least-> Scalar
, instead of-> CtOption<Scalar>
, which will never have theNone
variant. Isn't guaranteed invertibility one of the major uses of aNonZeroScalar
type?The text was updated successfully, but these errors were encountered: