Feature Request: Ref type for {BigInt|BigUint}

[TennyZhuang]

Propose to introduce the BigIntRef and BigUintRef type, and the definition should be:

struct BigUintRef<'a> {
    data: &'a [BigDigit],
}
struct BigIntRef<'a> {
    sign: Sign,
    data: BigUintRef<'a>,
}

And implement all ops on them.

The feature is useful when we want to store a list of BigInt or BigUint in a flatten memory and apply op on them without a whole clone.

[cuviper]

The internal layout ofBigDigits is an implementation detail, and I don't see how we could support arbitrary slices without exposing that. Plus, duplicating all ops on these ref types would be a large burden, and even more so if that also mixes operations with the normal non-ref types and primitive integers as operands.

It may be more feasible to support BigUint<A> and BigInt<A> for A: Allocator, once the standard library stabilizes those APIs for Vec<T, A>. Then we'd just be making our types more generic, and you could use things like &'a Bump for your flattened memory.

apply op on them without a whole clone.

For any ops that would work on such Ref types, can't you already just use &BigInt or &BigUint without cloning?

[akubera]

For the BigDecimal crate I added a BigDecimalRef<'a> struct which wraps a &BigUint which has worked pretty well for me.

pub struct BigDecimalRef<'a> {
    sign: Sign,
    digits: &'a BigUint,
    scale: i64,
}

https://github.com/akubera/bigdecimal-rs/blob/5eb7c228dea390de538aa6d35eb84d76fbf8f9d7/src/lib.rs#L1242

All the (non-mutable) methods need to be duplicated for the Ref struct (or rather moved, as the &self -> BigDecimalRef is trivial, so they're just thin calls fn method(&self, ...) { self.to_ref().method(...) }

The suggested implementation would work:

#[derive(Clone,Copy)]
pub struct BigIntRef<'a> {
   sign: Sign,
   mag: BigUintRef<'a>,
}

#[derive(Clone,Copy)]
pub struct BigUintRef<'a> {
  data: &'a [BigDigit];
}

A mutable BigIntRef would allow (for example) a no-clone abs() method which changes the sign, leaving the digit data alone.

With such a ref struct, I'd be able to change my impl to:

pub struct BigDecimalRef<'a> {
    sign: Sign,
    digits: BigUintRef<'a>,
    scale: i64,
}

So the ref would contain the slice, rather than reference to the uint which contains the vector.

[Eh2406]

It may be more feasible to support BigUint<A> and BigInt<A> for A: Allocator, once the standard library stabilizes those APIs for Vec<T, A>. Then we'd just be making our types more generic, and you could use things like &'a Bump for your flattened memory.

While we wait for STD to stabilize Allocator, would you be comfortable with a nightly_allocator feature that provides a way to opt in the unstable behavior? Alternatively would you be comfortable with feature that uses allocator-api2?

Edit: I spiked out using allocator-api2, and it is not pretty. The header of every impl block needs to add <A: Allocator> ... for BigUint<A>, and there is no clean way to switch based on cfg(feature = . Duplicating the entire API Is not worth it, so a feature is right out. But if we always use allocator-api2 then we have BigUint<A: Allocator = Global> witch is worth a try. Unfortunately, a bunch of the num-traits end up unhappy. For example, One has is_one and set_one that do not care about the allocator and one that does. We could implement it only for Global, but that is not grate. Integer is even more of a mess. Some of them have multiple output that should not be required to be from the same allocator.