Hm? JavaScript BigInts are arbitrary precision, and you need to use methods like BigInt.asIntN(64, a) to convert them to 64 bits
replyI hate this so much because you can’t nicely serialise a BigInt as JSON. Using a string is nicer but it
only makes sense where int64 is used as an ID, not where it’s used as a number; and you don’t wanna have to configure this per field per query.
replyIMO, I'm tending toward thinking that having types on your readable serialization format is a mistake, and that they should be always input to the (de)serializer instead.
replyYou can serialize a BigInt by specifying a replacer:
reply const obj = { a: 9007199254740993n }
JSON.stringify(obj, (_key, value) => typeof value === 'bigint' ? JSON.rawJSON(value.toString()) : value)And then you end up with strings on the other side, not numbers.
replyNo you don't? The example I gave produces
reply {"a":9007199254740993}
{"a":"9007199254740993"}Oh, that's much worse! The JSON string `{"a":9007199254740993}` decodes to the object `{"a":9007199254740992}` with typical JSON parsers like JavaScript's `JSON.parse`.
replyIf you're applying a replacer, then you'd supply a reviver when parsing:
reply const json = '{ "a": 9007199254740993 }'
JSON.parse(json, (_key, value, context) => /^\d+$/.test(context.source) ? BigInt(context.source) : value)Yeah but now you have the world's biggest foot gun in your API.
replyJSON has arbitrary length numbers in the spec only.
replyCompletely and utterly irrelevant.
replyThis is simply not true? Or maybe I misunderstand what you mean?
reply