Expose Unescape + AppendUnescape helper functions

[lab176]

Similar to #60, this pr introduces and exposes Unescape() and AppendUnescape helper functions.
These simply mirror and inverse the recently exposed Escape and Unescape functions.

[achille-roussel]

Should s be of type []byte ?

[lab176]

you're fast..
Likely.. it's awkward here but I figured i'd keep the same pattern as the above Escape and AppendEscape functionality. Open to reversing it

[achille-roussel]

The reason I'm suggesting it is because Escape returns a []byte, so it's a bit strange to have the reverse function work with a string. Besides the inconsistency, we'd end up forcing a type conversion on the program if it needs to escape and unescape.

This would also remove the need to do the string-to-bytes conversion in your implementation, which requires a heap allocation and copy of the content.

[lab176]

It seems I don't have access to snyk to investigate these failing tests, will look around for what these are doing.

update: seems like they resolved themselves

[stevevls]

Should one of the arguments to decodeString be b? I'm not seeing how the storage allocated for b would actually be written to if we're not pushing it down the call stack. 🤔

[achille-roussel]

Actually, thanks @stevevls for your call out.

This looks wrong doesn't it? Assigning b and returning s?

[stevevls]

I'm not super familiar with this code, so bear with me here. 😁 Is it possible to decode straight into b to avoid allocating to buf and then copying?

[lab176]

unlike encodeString(), decodeString() does not append the result string to the buffer passed it, rather it simply overwrites the string at the pointer passed in:
*(*string)(p) = string(s), where p is the passed in buffer. I'd like to avoid modifying the underlying function for this simple change, but perhaps there are options I am be missing!

[achille-roussel]

Maybe using decodeString isn't the right approach, have you looked into parseStringUnquote ?

[achille-roussel]

I guess you'd have to reimplement the handling of parsing flag, maybe that's not the right path.

[achille-roussel]

Do you think we could add a benchmark to validate that there are benefits to using json.AppendUnescape compared to json.Unmarshal ?

[lab176]

Do you think we could add a benchmark to validate that there are benefits to using json.AppendUnescape compared to json.Unmarshal ?

Yeah I'll do this, good call.
fwiw, our specific use case will not use AppendUnescape- we simply need to unescape individual fields pulled from the json object, as the optimization is specifically to avoid processing the entire object. I included it to pattern match the exposed Escape functions. I'll add the benchmark, but perhaps it can be avoided until its necessary.

[achille-roussel]

Often times, these can be a good enough approaches:

var v struct {
  Field string
}

json.Unmarshal(b, &v) // will only unmarshal `Field` from a large JSON payload

var s = []byte(`"hello world!\n"`)
var v string

json.Unmarshal(s, &v) // this will unescape the JSON string `s`

[lab176]

benchmark results:

BenchmarkUnmarshalField-12    	 2908604	       425 ns/op	     256 B/op	       3 allocs/op

BenchmarkUnescape-12    	 4048627	       290 ns/op	      64 B/op	       2 allocs/op