What problem does this solve or what need does it fill?
Current implementation of ReflectDeserializer uses deserialize_any to deserialize objects which was serialized with ReflectSerializer, but there are many serde crates which doesn't support self-describing, like bincode or rkyv.
What solution would you like?
An alternative implementation of ReflectDeserializer which doesn't uses deserialize_any, which will allow both self-describing and non-self-describing serde crates to be used with.
What alternative(s) have you considered?
Not using non-self-describing crates, but non-self-describing crates usually have better serde performance.
Additional context
The docs of deserialize_any also states a similar thing:
Require the Deserializer to figure out how to drive the visitor based on what data type is in the input.
When implementing Deserialize, you should avoid relying on Deserializer::deserialize_any unless you need to be told by the Deserializer what type is in the input. Know that relying on Deserializer::deserialize_any means your data type will be able to deserialize from self-describing formats only, ruling out Postcard and many others.
What problem does this solve or what need does it fill?
Current implementation of
ReflectDeserializerusesdeserialize_anyto deserialize objects which was serialized withReflectSerializer, but there are many serde crates which doesn't support self-describing, likebincodeorrkyv.What solution would you like?
An alternative implementation of
ReflectDeserializerwhich doesn't usesdeserialize_any, which will allow both self-describing and non-self-describing serde crates to be used with.What alternative(s) have you considered?
Not using non-self-describing crates, but non-self-describing crates usually have better serde performance.
Additional context
The docs of
deserialize_anyalso states a similar thing: