The math/big.Int type already supports the MarshalJSON and UnmarshalJSON methods. Thus, fields of that type should already handle big numbers. Thus, in the function you are pointing to, *big.Int should be handled here:

That being said, math/big.Float does not support MarshalJSON and UnmarshalJSON. If that's the case, perhaps those methods should be added instead? I don't believe json should gain a dependency on big.

Edit: Nevermind. json calls the UnmarshalText methods if it is present.

@dsnet Yup, I'm aware of that, which I acknowledge in the addendum to my proposal.
Not wanting json to depend on math/big is a fair opinion.

When you say dynamic runtime, you mean something like this?

var m map[string]interface{}
json.Unmarshal([]byte(`{"k1": "string", "k2": null, "k3": 1234, "k4": 12345678901234567890}`), &m)
fmt.Printf("%T\n", m["k3"])
fmt.Printf("%T\n", m["k4"]) // you expect to see *big.Int?

@dsnet Yup! I actually found a workaround for my particular use-case, but I made this issue to probe interest in enabling exactly the code you've written.

I'm slightly against this, since JSON in practice has to interact with the least common denominator of all the JSON in the ecosystem, and JavaScript can't even handle 64-bit integers, so I can't imagine there's many JSON documents in the world with a JSON number with so many digits that it'd overflow int64 or uint64 (the latter of which Java doesn't have either).

I could be convinced if you somebody presented actual uses cases of JSON in the wild with such huge and unquoted number literals, and pointed out how other JSON parsers transparently deal with it.

No one will expect *big.Int in the interface. It sounds like in your program you should be using json.Decoder.UseNumber.