BigInt const generics

[mmagician]

Description

This is an updated PR based on the subset of #186, i.e. replacing the macros with const generics only for BigInt crate. As such, it should be easier to merge.
Breaking change -> will need an accompanying PR in the curves repo.

---

Before we can merge this PR, please make sure that all the following items have been
checked off. If any of the checklist items are not applicable, please leave them but
write a little note why.

• Targeted PR against correct branch (master)
• Linked to GitHub issue with discussion and accepted design OR have an explanation in the PR that describes this work.
• Wrote unit tests
• Updated relevant documentation in the code
• Added a relevant changelog entry to the Pending section in CHANGELOG.md
• Re-reviewed Files changed in the GitHub PR explorer

[burdges]

cc @tarcieri

[tarcieri]

I talked with @Pratyush about crypto-bigint in the past.

This PR is doing something somewhat similar, but the main difference would be crypto-bigint uses [Limb; N], where Limb is a newtype wrapper for u32 on 32-bit architectures and u64 on 64-bit architectures, which seems like it'd be a bigger change than what's in this PR, so perhaps this is a good incremental step if there's an eventual desire to use crypto-bigint in the future.

It sure would be nice to have one place to collaborate on these sorts of problems.

[Pratyush]

One additional thing we might want to consider doing is moving all the impls in the traits directly to inherent methods, and having the trait forward to those inherent impls. This would enable calling the BigInt methods in const contexts.

[Pratyush]

I think we can use the BigInteger::new method here to avoid specifying the number of limbs. (It's unfortunate that we can't use the type alias as the constructor =()

[Pratyush]

Ditto for the fixes in curves

[weikengchen]

One repo needs to move first. It can be algebra.

[tarcieri]

One additional thing we might want to consider doing is moving all the impls in the traits directly to inherent methods, and having the trait forward to those inherent impls. This would enable calling the BigInt methods in const contexts.

This is what crypto-bigint does but it does have a downside: it prevents the usage of intrinsics.

One workaround is to keep the intrinsics in the trait impls, and const pure Rust.

[Pratyush]

This is what crypto-bigint does but it does have a downside: it prevents the usage of intrinsics.

Good point.

One workaround is to keep the intrinsics in the trait impls, and const pure Rust.

Yeah, that's a good trade-off, but in that case we might need to name the inherent and trait methods differently, to avoid accidentally using the slower one. Maybe it's just better to wait for const in trait impls...