>
> The problem with a `big_int operator+(big_int lhs, big_int rhs)`
> signature is that lvalue arguments cause an unnecessary ref-count
> inc+dec, even for basic arithmetic.
>

You're right. That may have been fine in another library, but does not seem
suitable for standardization.


> Another option is to have a possibly-owning big_int_view type, which
> you'd use like `big_int operator+(big_int_view lhs, big_int_view rhs)`.
> big_int_view has same layout as big_int, plus an additional "owning"
> flag. When initialized from an lvalue (big_int or big_int_view) it
> (shallowly) copies the value without taking ownership. When initialized
> from an rvalue it copies the value and takes (or inherits) ownership,
> clearing the source. This saves you the separate const/rv overloads, and
> avoids the extra indirection of a reference.


I feel like the cost of having this whole new view type is higher than just
adding a couple of boilerplate overloads.

You also need to consider that operator+ should work if one of the operands
is an integer. I think to handle that without avoidable overhead, you
actually need operator+ to be a function template. The reason is that for
example, __int128 may not fit into big_int without extra allocation,
so (big_int +
__int128) would require an extra allocation to fit the right side, even
though the operation could be performed with only the left allocation
involved. I don't think big_int_view can handle the __int128 case in any
reasonable way; you cannot do that without ownership.