Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow deserializing strings as sequences to not allocate on strings with escape sequences #321

Open
oli-obk opened this issue May 15, 2017 · 2 comments

Comments

@oli-obk
Copy link
Member

oli-obk commented May 15, 2017

"\"foo\"" needs to be deserialized into a heap allocated string first and then parsed further.

#318 gives one alternative to the allocation by rewriting the original input.

If the input cannot be modified, another alternative would be to allow deserialize_seq to produce a sequence of characters or bytes instead of going straight for the string.

@clarfonthey
Copy link

That's actually an interesting idea: you could definitely do zero-copy for sequences by deserializing to an iterator. Would require upstream serde support, though.

@dtolnay
Copy link
Member

dtolnay commented May 15, 2017

I don't think this would require any further upstream support, since SeqAccess is already effectively an iterator.

The only change here would be intercepting deserialize_seq and, if the input contains a string, driving the visitor with a sequence of bytes or chars instead of with a string.

I'm not yet sold on this idea because it would be detrimental to error messages in some cases. For example if you are deserializing struct S { clars: Vec<Clar> } and the input is {"clars":"lololol"}, you should currently get an error that a sequence was expected but the input contained a string, whereas with this change you would get an error that a struct Clar was expected and the input contained a char 'l'. We would need to figure out how to mitigate that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Development

No branches or pull requests

3 participants