This gives a unified trait for our BigInt backend in a way that allows us to abstract over the backend.
This problems with using features:
Any library using curv had to either use the default gmp backend or explictly replace it with num-bigint, or add their own features that change the features in our library.
If any other library in the dependency tree enabled a different backend it would fail compiling.
The combination of these meant that in practice it was hard to actually allow the end user(binaries) to choose their desired backend.
Furthermore, this change will allow users to implement the BigInt trait to their own backends, and allows us to add more backends more easily.
I'm still debating myself if it's better to use a trait or a wrapper like struct BigInt<B: BigIntBackend>(B) that will use the trait to provide method and trait implementations.
This gives a unified trait for our BigInt backend in a way that allows us to abstract over the backend.
This problems with using features:
curvhad to either use the default gmp backend or explictly replace it withnum-bigint, or add their own features that change the features in our library.The combination of these meant that in practice it was hard to actually allow the end user(binaries) to choose their desired backend.
Furthermore, this change will allow users to implement the
BigInttrait to their own backends, and allows us to add more backends more easily.I'm still debating myself if it's better to use a trait or a wrapper like
struct BigInt<B: BigIntBackend>(B)that will use the trait to provide method and trait implementations.I also replaced https://crates.io/crates/rust-gmp-kzen with https://crates.io/crates/rug which is a nice wrapper around libgmp and is actively maintained