New Issue: [Library Stabilization] bigint size and sizeinbase questions

17693, "lydia-duncan", "[Library Stabilization] bigint size and sizeinbase questions", "2021-05-12T18:56:00Z"

bigint.size() returns size_t but bigint.sizeinbase() returns uint. Both call down to mpz wrapper functions that return size_t but they declare different return types (and the return value gets cast by the compiler to uint as a result). Should these return the same type? If so, should it be size_t or uint or int? (I lean towards "yes" and "uint", but I'm okay with returning "int")

I don't think there's a scenario where these return the same value. bigint.size() returns the "number of limbs" used to store the number while bigint.sizeinbase() returns the number of digits that would be used to express that number in the given base.

If we decide to continue returning size_t from bigint.size(), does this mean we should make the use of SysCTypes in the BigInteger module public?

Brad says:

I'd be inclined to have [these both] return int along with our discussion with the range module to have all .size() routines return default int (I don't interpret this as a "hard and fast" decision yet, but I think it got a lot of positive support and makes sense for our language; we can have a .sizeAs(type t) routine if/when someone needs it returned as a different type, but I'm not sure I'd worry about that until then.

Michael initially went for uint as well but is mostly more in favor of using Chapel types over C types (which I agree with)