On Wednesday, April 15th, 2026 at 7:31 AM, Jan Schultke <janschultke_at_[hidden]> wrote:

> >
> > * Regarding the from_range constructor, is determining the signedness of
> > the encoded value based on the signedness of the range's value type the
> > right API? I mean, it sort of makes sense, but I'm still on the fence.
> > The individual digits themselves are technically not signed integers
> > (their MSB is not a sign bit, except for the last), and are probably not
> > stored as such.
>
>
> I don't know if the design of that one is good. I think it makes a bit of sense since it lets you construct from any other integer type, and communicating whether it's signed or unsigned seems pretty natural. This is useful when e.g. bit-casting a signed _BitInt(4096) to some limbs and constructing big_int from that, although to be fair, that is already provided directly via another constructor.
>
> > Should there be a way to treat the range as big-endian (in term of the
> > element order)? The range might not be reversible, but the big_int storage
> > is.
>
>
> That sounds like a general problem that applies to all from_range constructors in the standard library. I don't really know how you would find yourself in a situation where you can't reverse the range anyway. In multiprecision, you basically always work with contiguous ranges, so it's always possible to run one through std::views::reverse.

I was thinking about things like reading a big int from a file, where you
only have an input range, without needing an intermediate buffer. If
signedness were a separate parameter, then maybe endianess could go along
with it. But again, I'm not sure about it either way.

>
> > In the "throws" section, you don't know ahead of time if the value
> > requires an allocation or not, so you can't give that promise (plus, the
> > iterator itself can throw).
>
>
> I didn't think of the iterator throwing, but you don't need to know in advance if the value will fit for unsigned integers at least. You can just insert limbs into inplace storage as long as they fit, and if you run out of space, start allocating. However, maybe that doesn't work for negative integers passed via input range because you get an ever-increasing sequence of 1-bits, and once you hit the sign bit, you may realize "OOPS, I only need one limb to store this" because the number turns out to be minus one or something.

You can also have leading (trailing?) zeros in an unsigned range. I guess
you can make the wording more specific, like limit it to cases where
there's no leading zeros/ones, or to reversible ranges where you can trim
them. I don't know if it's worth it.