Yeah, always better to say what I REALLY want than to try and second guess the implementation, eh
OK... What I have is an existing library that kinda does a double-deserialization that uses
serde_json - I'm trying to improve it and make it work properly with
The "toplevel" deserialization is done like this...
Deserialize. In the
deserialize method the first thing it does is this...
let raw_value: Box<RawValue> = Box::deserialize(deserializer)?;
let data = raw_value.get();
Then it does a bunch of trial and error
serde_json::from_str(s).map(Whatever.into) //or similar
until one works, which it then uses to return the appropriate variant of
That has two problems ... it's "ugly" (trial an error) AND there's something about
simd_json that does not play well with
serde_json RawValue (issue logged).
So, what I'm trying to do is have roughly the same approach, but get some kind of minimal interrogable structure out of the deserializer, look for type determinants in that structure, then, based upon the determinant found, directly invoke the second deserialize from that structure to the target type.
serde_json Values work but they are expensive to create - using them runs considerably slower than the
RawValue approach (albeit that they work with
simd_json - but with no speed up).
simd_json has a "Tape" - a simple structured deserialization that is neither a DOM
Value nor a target Type. BUT the only way I can see of turning a
Deserializer into a
Tape is the
to_tape method on the
simd_json Deserializer struct.
So I was looking for a way to "know/tell" that the incoming deserializer in the AnEnum
deserialize method is, in fact, a
simd_json Deserializer. (It's another question, how to take the
Tape as input for the next deserialization - but that's for another day).
If it isn't at all possible I do have the option of making deeper cuts to the original library and eliminating the
Deserialize semantics of AnEnum - it's all private anyway - it's just that I'm trying to implement a feature that switches out
simd_json and so my first attempts are trying to keep basically the same code approach.
The closest I've got is an extension trait with a default implementation - but it appears that the default implementation is always called.
Any help would be appreciated.