Is your feature request related to a problem? Please describe.
For some cases, JSON encoding of data may be too large, or there may be other requires around using a binary format. BSON is one such popular format.
It can be useful for an application be able to transparently support reading either JSON or BSON. In order to avoid needing to implement two completely separate loading/parsing code paths, having yyjson support parsing BSON would thus be highly beneficial.
The same is true for enabling a yyjson-based application to write either JSON or BSON.
Describe the solution you'd like
Either new yyjson_read_bson_opts and yyjson_write_bson_opts functions, or new read/write flags to accomplish the same. The formats are entirely different so separate functions feel to me like the better approach.
Describe alternatives you've considered
Writing a separate library on top of yyjson with custom read/write functions that reuse the yyjson data structures. That is an entirely viable alternative to me vs adding more complexity to yyjson itself, though I do think it would be more convenient for users to have the functionlity bundled.
Additional context
There are numerous other binary JSON encoding formats or adjacent formats like Avro/Thrift/etc., just like there are numerous other enhanced JSON encoding besides JSON5. That said, BSON seems to be the one most aligned with yyjson in that it's just a binary JSON encoding without extra features (that yyjson would have to handle when parsing) or without limitations on encoding format (that yyjson would have to handle when writing). If yyjson is to support any binary encoding, BSON is the one to do.
The only feature I'm aware of that BSON has which yyjson does not otherwise handle directly would be decimal floating point support. These could be stored as raw values, of course, but yyjson would either need to add a new DECIMAL subtype for these or elect to not support them and raise on error if encountered while reading.
Is your feature request related to a problem? Please describe.
For some cases, JSON encoding of data may be too large, or there may be other requires around using a binary format. BSON is one such popular format.
It can be useful for an application be able to transparently support reading either JSON or BSON. In order to avoid needing to implement two completely separate loading/parsing code paths, having yyjson support parsing BSON would thus be highly beneficial.
The same is true for enabling a yyjson-based application to write either JSON or BSON.
Describe the solution you'd like
Either new
yyjson_read_bson_optsandyyjson_write_bson_optsfunctions, or new read/write flags to accomplish the same. The formats are entirely different so separate functions feel to me like the better approach.Describe alternatives you've considered
Writing a separate library on top of yyjson with custom read/write functions that reuse the yyjson data structures. That is an entirely viable alternative to me vs adding more complexity to yyjson itself, though I do think it would be more convenient for users to have the functionlity bundled.
Additional context
There are numerous other binary JSON encoding formats or adjacent formats like Avro/Thrift/etc., just like there are numerous other enhanced JSON encoding besides JSON5. That said, BSON seems to be the one most aligned with yyjson in that it's just a binary JSON encoding without extra features (that yyjson would have to handle when parsing) or without limitations on encoding format (that yyjson would have to handle when writing). If yyjson is to support any binary encoding, BSON is the one to do.
The only feature I'm aware of that BSON has which yyjson does not otherwise handle directly would be decimal floating point support. These could be stored as raw values, of course, but yyjson would either need to add a new DECIMAL subtype for these or elect to not support them and raise on error if encountered while reading.