Remove escaped solidus from writer

[samkes]

Though a forward slash may be escaped it is not required and can break some use cases. I was trying out this library for Json logging and having solidus escaped breaks literal comparisons with many text tools.

For example, when using grep to search a log file named logfile for the url 'https://github.com' one would have to write the following command:
grep "https:\\\\/\\\\/github.com" logfile instead of the expected grep "https://github.com" logfile

The 4 backslashes in the example is because one has to escape the characters from the shell as well, while in other circumstances one should supply only 2, which only serves to complicate matters.

[Tornhoof]

Yes, it is optional. Many implementations, including this one, escape more than actually required. Escaping the solidus, for example, helps with embedding json in certain other Media types.

One of the original reasons to have directly encoded string (Encoding.Unicode) support was to allow embedding the data (or rather read embedded data) from different media.

This won't be changed any time soon, I'm sorry.

[samkes]

Yes I am aware that many would like it escaped when the result is to be embedded in HTML and some other cases. Shouldn't it be configurable then to support all use cases?

I would appreciate some hints on where to put this configuration. Would adding a StringEscapeOptions enum to SpanJsonOptions be a good choice?

[Tornhoof]

If I remember correctly, all of my attempts to make this happen were unsuccesful, due to perf problems, short of duplicating the API and adding it to the resolvers, formatter, Expression trees etc. And that was way too much work. So yeah, the Options would be correct, then add Methods to the writer (e.g. WriteUtf8StringMinEscaped (which then duplicates the normal WriteString API, but only with mandatory escaping) and use these Methods in the Expression tree Logic etc.
But that's a lot of work. If you need a version which only escapes the mandatory values, i'd recommend branching. It is highly unlikely that much dev will happen in SpanJson anyway, as I 'm, frankly spoken, over runtime code Generation.

[samkes]

Thanks for the suggested solution. Guess I'll see if I think it's worth the work.