Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This is really cool. But how does zero-copy deserialization work for &'a str with formats like JSON where the input data may have string escapes (and therefore needs to be mutated during deserialization)?


It doesn't. You can use Cow<'a, str> if you want string escapes to work, but then it is not really zero-copy anymore.


So, what, if you use &str you get the raw data, escapes and all? That's not very good, especially because it means round-tripping your struct through JSON can return the wrong result.

I assume that Cow<'a, str> will only produce an owned string if there are strong escapes that need decoding? If so, that's probably the best approach for decoding appropriately, as you'd get zero-copy as long as no mutations are required, but round-tripping through JSON would still work right.


That makes sense. I want to rewrite my plist parser to both use Serde and be zero copy (https://github.com/conradev/plist-rs/issues), and for binary plists you would similarly need to convert UTF-16 strings to UTF-8, but wouldn't need to touch UTF-8 strings.

I wonder how the API would work. Would json::Value be modified to have a lifetime and contain Cow enums? How would it implement ToOwned? It almost seems like there would have to be separate types, a json::Value<'a> and json::OwnedValue.


Yes, I don't think you can do better if forced to use &str. The point of using Cow is indeed to only copy when necessary like you assumed.

You could have zero-copy roundtrips if you used escapes in the deserialized strings as well.


For the record, I just tested, and it turns out that if you try and decode a string with escapes into a &str, it produces an error rather than giving you the escaped version of the string.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: