[jerf]

Floating point types are tagged by the use of the floating point grammar. It would require the standard to be clear that the only way to indicate integers is via "i:288", though, or there will be ambiguity.

I don't know if that circle can be squared, either; if you require integers to use the tagged string, it isn't really backwards compatible any more. If you don't, the floats remain ambiguous.

Given that the text of the blog post suggests, probably correctly, that new parsers will be necessary to use this format, I'm not convinced that trying to reuse JSON's grammar is that advantageous. If I'm switching parsers, the competition is no longer JSON, it's the full range of possible replacements, including Protocol Buffers, Cap'n Proto, XML, BSON, and everything else. If you're willing to replace parsers there's probably already something out there for you.

[bascule]

It would require the standard to be clear that the only way to indicate integers is via "i:288", though, or there will be ambiguity.

The spec does this here:

https://www.tjson.org/spec/#rfc.section.4.3

  4.3.  Floating Points

     All numeric literals which are not represented as tagged strings MUST
     be treated as floating points under TJSON.  This is already the
     default behavior of many JSON libraries.

If I'm switching parsers, the competition is no longer JSON, it's the full range of possible replacements, including Protocol Buffers, Cap'n Proto, XML, BSON, and everything else.

As noted in the post (which names a similar list of binary formats), TJSON is intended to be supplemental to binary formats, not a "replacement"

[jerf]

Thank you. I skimmed over that accidentally. Good.