> Should we consider also making every "possibly lossy" conversion to or
> from std::big_int explicit?
>

Yeah, there's a good argument in favor of that design.


> It sounds like you intend for std::big_int to include the possibility
> of dynamic allocation. Would you consider instead separating out the
> "fixed-size, stack-allocated" case from the "possibly dynamically
> allocated, possibly reference-counted" case?
>
> I suspect most users will reach for the fixed-size, stack-allocated
> case. I would use it for software emulation of floating-point
> numbers, for example. The dynamically allocated, possibly huge case
> is important for some users -- LBNL's David H. Bailey has written
> about this -- but it seems a lot more specialized.
>
> Limiting consideration to "a more C++ - friendly _BitInt(N)" (stack
> allocated, bounded size, no lossy implicit conversions, no integer
> promotions) might help bound the work.
>

The problem is that I think _BitInt is all we need for the fixed-width
case, and even if we could have a more C++-style type that's mildly better,
the cost of ecosystem fragmentation and added
standardization/implementation burden outweighs the very mild benefits over
_BitInt.

People are free to propose some kind of fixed-width wrapper for _BitInt,
but I won't be pursuing that. I am interested in the arbitrary-precision
(dynamically allocated) type.