> - Can we get the core algorithms (operating on byte streams or so),
>> independent of the memory management concerns?
>>
>
> I was drafting up something along those lines at some point, but you can
> only do so for a handful of operations, such as addition and bit-shifting.
> Once you do multiplication, division, or many other operations, you need
> additional allocations to store temporary results, and I don't see much
> value in standardizing the core algorithms if those are ridden with an
> unspecified amount of extra allocations. std::big_int would be used in
> its own implementation, so to speak.
>

When drafting up those functions, I also realized that it's very useful to
have overloads for limb spans and for integers. For example, when you take
the remainder and the divisor is int, the result has to fit in an int,
so a std::multiprecision_rem(std::span<const
limb_type>, int) would return int. This is quite convenient compared to
only working with spans and performing runtime checks to see if you have a
single limb.

This very quickly leads to explosion in overload count and much more
complicated interfaces with various combinations of spans and integers. It
turns out that std::big_int also solves that: if it can cheaply store a
small dividend and/or divisor you can simply have operator/(big_int,
big_int) which returns big_int.