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
"\"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.
The text was updated successfully, but these errors were encountered:
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.
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.
"\"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.The text was updated successfully, but these errors were encountered: