Default handling for escaped strings

[stephenberry]

Right now Glaze defaults to checking all string like types (e.g. std::string) for escape characters. This adds overhead to reading/writing.

simdjson (on demand) does not default handle escape characters, it is an opt-in for users.

It seems bad to make everyone pay for escape character handling when there are many times it isn't used.

Right now the faster approach is opt-in via:

glz::read<glz::opts{.raw_string = true}>(...);
// or with the wrapper
glz::raw_string<&T::string>

We could make the escape handling opt-in like:

glz::read<glz::opts{.raw_string = false}>(...);
// or with the wrapper
glz::escaped<&T::string>

For general use cases you can expect to see a 10% speed improvement when reading/writing when not handling escapes.

I've decided to make the default behavior handle escaped strings, for proper JSON compliance. Thanks for the feedback!

[Curve]

I think this is a rather tough decision, I'd say go faster by default (as simdjson does it already, I think this wouldn't hurt) but make it very clear that escape handling is opt in

[stephenberry]

Yeah, it would definitely have to be a bold statement at the top of the README for new users.

[Haatschii]

The phrasing of the question is ambiguous is it not? I think "Yes" and "No" have to be switched to align with the text in the parentheses (or the parentheses should be switched) . Not sure which side I should choose now. ^^

However I do tend towards maintaining full JSON string support by default and leaving the speedup on as an op-in option. Using the current raw string option really isn't hard.

[stephenberry]

You're right, my title was off. I updated it, thanks. I do feel it is safer to support escaped keys as you said it isn't hard to opt into the niche performance case.

[justend29]

Definitely handle escape sequences by default. Ideally, a JSON library should properly handle JSON, including escape sequences within string. simdjson has positioned itself such that boosting its benchmark is the only concern. That's fine, but surprises in a production environment when an escape sequence is received without realizing they're not handled sounds problematic - more problematic than a 10% performance bump for the one field.

[justend29]

@stephenberry I'm trying to catch up on the new modifiers/wrappers added recently. Since escaping is the default, is glz::escaped to reinforce the default behaviour of handling escape sequences?

[stephenberry]

Yeah, wrappers like escaped or raw_string can be local to nested objects. So, a user might want to define reading a top level object with raw_string, but have one field in a child object that handles escapes using escaped.

[justend29]

Makes perfect sense, thanks!

[matttyson]

Hi, new user of Glaze here, I hope you don't mind me throwing my 2c in.

My preference would be to handle escapes correctly by default, and let the user decide if the performance / correctness tradeoff is worth it for their application.

I think there's too many footguns with not acting standards compliant by default. It was one of my big bugbears with older versions of MySQL back in the day, and why I always pick Postgres as my default DB. Speed is nice but correctness is mandatory. (well, that's my take anyway).

I've been using Glaze for a hobby project where I'm slowly porting it away from simdjson. I'm really enjoying it so far. Thanks for all your work on it!