You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In JSON you can include a double quote character in either keys or values by prefixing it with a backslash. This unfortunately means that the source deviates from content. Currently these are un-accounted for.
Processing the strings could
Be overhead, might require allocating all strings
Break the ability to pattern match on them
One method is just to bear this in mind when using the library. If it is important then leave the user to handle them on their end (same way that numbers are not processed into f64 or another form)
Some questions to consider
Is it worth making things more verbose or slower to cater for an edge case
How prevalent are " in JSON keys and values?
What other characters can be escaped
Is supporting this via a feature flag a good compromise or confusing?
The text was updated successfully, but these errors were encountered:
Interesting! I did not know that Cow has a special AddAssign implementation for str so that you can do += without it allocating character bytes. Will figure out a way to reverse that for encoding/un-escaping.
That can handle the JSON string values. As for keys, not sure about changing the keys as wouldn't work with the current pattern matching examples. Maybe can look if/when match_deref for strings is a feature (hopefully it can work across Cow). However in the meantime there could be another API using a function, which can internally equate the strings handling escapes (ignore backslashes).
In JSON you can include a double quote character in either keys or values by prefixing it with a backslash. This unfortunately means that the source deviates from content. Currently these are un-accounted for.
Processing the strings could
One method is just to bear this in mind when using the library. If it is important then leave the user to handle them on their end (same way that numbers are not processed into
f64
or another form)Some questions to consider
"
in JSON keys and values?The text was updated successfully, but these errors were encountered: