You can define a toJSON property on the BigInt prototype that gets used for serialization:

    Object.defineProperty(BigInt.prototype, "toJSON", {
        get() {
            "use strict";
            return () => String(this);
        }
    });

Of course you could also serialize to a Number, but that risks losing precision. For example, the Twitter API often returns IDs as both a Number ("id") and a String ("id_str") to safely handle cases where the value might fall outside of a normal double-precision float: https://developer.twitter.com/en/docs/tweets/data-dictionary...

I'm sure its for backwards compatibility but hot damn is that one hell of a footgun. Even with that in place would you ever feel confident returning an id that didn't fit in a double knowing the sheer amount of code that definitely didn't handle that case?

Only Strings are safe,

forty years past K&R.

Wish I knew Tcl.

I like your haiku.

But stay away from TCL...

It is such a mess.

I love TCL, personally. It's my favorite language to play around in.

Fixed it for you:

> I love TCL.

> It's my favorite language

> to play around in.

Your attempt conflicts with both previous haikus. By their evidence, "TCL" is only two syllables, but you treat it as three.

This does make me curious how they're pronouncing TCL in two syllables, though.

TCL is pronounced "tickle." https://en.wikipedia.org/wiki/Tcl

> third party ids are not yours. Treat them as strings, the other party can change them to string any day (happened to me more than once over the years) or they could use a different integer size than what you support (this case, or an unlimited integer value type - some languages have that too)

Only in JS do people seem okay with constantly mucking with built-ins.

Ruby has a culture around it too: https://www.justinweiss.com/articles/3-ways-to-monkey-patch-...

And you can get some of the patching effect in any language with uniform function/method calls, though typically with a little more scoping and thus less ability to inflict unexpected side effects: https://en.wikipedia.org/wiki/Uniform_Function_Call_Syntax

For pretty much the past decade (specially the last few years) I feel the culture has shifted to consider core monkey patches as a pretty bad practice.

Sure, but it's also a bad practice in Javascript.

And Swift! https://docs.swift.org/swift-book/LanguageGuide/Extensions.h...

If people could muck with builtins in Python, they would. And worse, they'd do it with inheritance and metaclasses. I say this as a Python dev.

Python3 mucked with built in types...

I don't think monkey patching is really common in any version of python. I've not seen it done anywhere.

Setuptools monkeypatches distutils. Pip always uses setuptools so pretty much everything installed via Pypi is the fruit of a monkeypatch.

Talking about the intro of bytes, bytearrays and the not quite the same types that were backported to 2.x

Afaict, JSON serialization is not supported yet, got a "TypeError: BigInt value can't be serialized in JSON". I'm on Firefox Developer edition 68.0b3.

I suppose one could use a replacer[0] when calling JSON.stringify and a reviver[1] when calling JSON.parse

[0] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

[1] https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

You can certainly serialize to a string but knowing when you should revive to a BigInt seems tricky. You could prefix the strings I guess?

How about serializing to an array ["bigint", "170141183460469231731687303715884105727"]? It takes more space, but is easy to recognize, and easy to generalize to other types.

Presumably that could be confusing if you ever happen to have an actual array whose first element is the string "bigint".

Well, no matter what you do, surely you plan on documenting your API to such a bare bones level that your user isn't racking their brain whether a key is a number or an array of data.

Nah, you just have to also encode all arrays like

    ["array", [...]]

;-)

True, but if you control both the serialisation and deserialisation you can get away with it

Reuse the literal? (postfix with 'n')

You don't want strings that are "digits..n" to automatically deserialize into bigints. What if you have a string like "8n", which is a tractor model, or "9n", which is a smartphone model?

But it would be nice to have literal 8n to convert to a bigint 8n. That's not in the JSON standard though.

JSON serialization does not seem to be supported yet. `JSON.serialize(42n)` gives me a TypeError "Do not know how to serialize a BigInt" in Chrome. Deserialization support also doesn't exist as far as I'm aware. Would be great to be able to choose to decode integer JSON literals as BigInt, but I'm not holding my breath.

You could decode all of them as BigInt, but then you would be accepting a large overhead for the much greater number of constants like 1 or 42 where it's unnecessary. Everywhere you pass that JSON data would need to be updated to operate in terms of BigInt instead of number.

If you only decoded big ones as BigInt, you would have the same problem of updating the code but now you have 2 codepaths at every callsite!

It's perhaps a defect in the JSON spec that it doesn't have a provision to support BigInt, but it's not really clear what should happen!

You need some way of serialization that makes clear it was serialized as a BigInt and thus must be de serialized as a BigInt without the likelihood of it misinterpreting the data like 9n being a tractor model. A single indicator would be too error prone, so the schema has to be more complex. With that complexity it needs to perform and be (cheaply) verifiable.

Quickest thing I can think of is storing it as power of 2 + the difference ending with character n as good measure. It is easy to serialize/de-serialize and you can verify the number by re-serializing to be a proper BigInt and not for instance a String. Confusion still would be possible, but rare. So 1 would be stored as 0+1n, 42 would be stored as 5+10n, etc.