re-enable BigInt hexadecimal literals

[rfourquet]

As this reverts a change which apparently was uncontroversial (but not supported by solid arguments IMO, see below), I apologize in advance to re-open the discussion, and to try to have this decision reconsidered.

This tries to fix what appears to me as a useless and frustrating limitation: the impossibility to input arbitrary-precision numbers as hexadecimal literals. My first attempt (which proves my willingness to try to respect the earlier decision) at fixing this was to create a BigUInt <: Unsigned type to hold arbitrary-precision unsigned numbers (a thin wrapper over BigInt). After a couple hours of coding, it became clear that, even if the code complexity overhead was not big, no-one would want to maintain this new type, at least not in Base (BigInt alone is complex enough). But after all, BigInt is enough for most purposes where one needs a big Unsigned (e.g. as bit fields), which is helped by the fact that the BigInt uses "two-complement" semantics. Except that they can encode negative values. Having specific printing routines to represent them in hexadecimal would help using them as Unsigned: e.g.

julia> bighex(big(10)) # ...0 represents infinitely many 0 on the left
"0x...0a"

julia> bigbin(~big(1))
"0b...10"

For this last number, "...1110" is the mathematical representation of -2 using 2-adic numbers, i.e. there is some soundness to it.

So I claim that representing and inputing BigInt with hexadecimal/octal/binary literals has nothing wrong in itself. IMHO, enabling the literal 0x100000000000000000000000000000000 to parse requires only to document that hex-literals don't necessarily produce Unsigned numbers, so I updated the docs here.

The arguments for disabling parsing BigInt hex literals that I can recollect (from #11105 and #11130):

1. it could possibly lead to hard to find bugs

I'm not conviced honestly; sure, more complexity brings more possibilities for bugs; but Julia didn't use this argument to have only one integer type in Base...

2. "It would be great to remove the BigInt dependency from the frontend" / "bigints from literals make it harder to deploy a Julia runtime without needing gmp."

Well, as long as we parse decimal BigInt literals, this will remain the case.

3. having hex BigInt literals is pretty strange

it may appear so, until one needs them.

So my argument is that it is useful to have hex-literals for BigInt, and that it's surprising only if one believes that hex-literals must produce Unsigned numbers.

[JeffBezanson]

I agree. It's not a law of the universe that hexadecimal must give Unsigned numbers, and I see nothing wrong with writing big integers in hex.

[rfourquet]

I re-added the tests and updated the docs which where modified in #12760.

[fredrikekre]

``BigInt`` -> `BigInt`

[rfourquet]

Ok to merge?

[rfourquet]

Jeff was supporting the idea, but without explicit approval, I'm not sure to dare to merge it mysef. So gentle bump!

[StefanKarpinski]

This can be re-enabled at any point since it's an error now. I think the weird thing about these is that they use an input syntax that is supposed to produce unsigned integers but produces a signed integer type. Let's let this wait – we can always have the debate later and enable this in 1.x.

[StefanKarpinski]

Oh, I see the connection to the MT printing, just read that.

[rfourquet]

I'm very fine to wait, it was just convenient to flesh out a nicer print for MersenneTwister. As I said in the OP, I tried hard to avoid that by starting coding UBigInt, but it's a dead-end, as BigInt fulfils most of the needs that would be accomplished by a UBigInt, except the parsing doesn't work for now.

[StefanKarpinski]

Given that this provides a motivation for the hex syntax for BigInts, we could just do that.

[rfourquet]

Besides #25129 (the seed of a MersenneTwister, which is a Vector{UInt32}, is printed represented as an integer in hexadecimal format), I got a couple more use cases, involving the BitIntegers package

1. While manipulating cryptographic hashes stored e.g. as UInt256, it's nice to be able to input these hashes directly in the REPL and have that be interpreted as an BigInt
2. building on 1), the SafeREPL package allows to reinterpret BigInt literals typed at the REPL as UInt256 for example; but this needs to not be erroring on an hexadecimal number which doesn't fit an UInt128.

Given that support was expressed, I will merge soon barring objections.

[rfourquet]

Yet another argument for this change: Julia itself uses long hexadecimal digits to represent primitive types:

julia> primitive type UInt200 200 end

julia> reinterpret(UU, rand(UInt8, 25))[]
UU(0x616395f3cd92da91f682131e0a681693b380f61127cb303bc7)

julia> 0x616395f3cd92da91f682131e0a681693b380f61127cb303bc7
ERROR: syntax: Hex or binary literal too large for UInt128
[...]

That would be cool to be able to manipulate 0x616395f3cd92da91f682131e0a681693b380f61127cb303bc7 at the REPL, and have it be interpreted as a BigInt.