On Tuesday, April 14th, 2026 at 6:21 AM, Jan Schultke via Std-Proposals <std-proposals_at_[hidden]> wrote:

> For those still interested, I've joined forces with Matt Borland and Christopher Kormanyos on the project.
>
> - Implementation: https://github.com/eisenwave/std-big-int
> - Super early in-dev proposal draft: https://isocpp.org/files/papers/D4444R0.html
>
> Help is welcome on the implementation :)
>

Overall this looks very good, just some random thoughts:

* It's pretty vague from the wording what the actual representation is.
The reference implementation is sign-magnitude, but is that mandated?
The only place I see where it's completely unambiguous is unary operator-().

Especially, the definition of "effective width" seems to imply two's
complement. Is the effective width of "3" 2 bits, and of "-3" 3 bits?
(And what about "0"?)

* Should width_mag() return `floor(log2(x))` or `floor(log2(x)) + 1`?
It's defined (and implemented) as the former, but the name implies the
latter. The way representation() is defined in terms of width_mag()
definitely implies the latter. (Also, it's technically undefined for
negative values right now.)

* 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.

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.

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).