Allow the tape to be used in a standard serde::Deserialize #366
Conversation
|
Oh I just saw, it'll need a |
|
K, I'm on it
…On Mon, Jan 29, 2024 at 11:18 AM Heinz N. Gies ***@***.***> wrote:
Oh I just saw, it'll need a cargo fmt before passing the CI
—
Reply to this email directly, view it on GitHub
<#366 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADAKLWUBIV25QSJE2XALTYTYQ5ZODAVCNFSM6AAAAABCOLJXNKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSMJUGM4DANJVGA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
|
Hold of merging for now - the larger goal is to figure out how to take the deserializer in a serde::de::Deserialize implementation's deserialize method, get the Tape from it, do my "type determinant" searches, then turn the Tape back into the deserializer and pass it onto the discovered types. Obviously this PR enables that last bit, but it's getting the Tape from the "anonymous" deserializer that has me a bit stuck at the moment. |
|
I think a way of achieving this would be changing the implementation from |
|
Since Deserialize is foreign and so are Vec and any slice notation, we need a local Trait to cover them... thinking... Can't think of anything - no matter what gyrations I think of, it comes down to needing to "know" that the anonymous deserializer can give me a reference to the tape so that I can "peek" at the tape and find the type determinants. I can't think of any way to do that (I'm constrained to using the serde Deserialize(er) in the framework to which I'm adding simd_json support)... Ohhhh - wait - an extension trait! Testing... |
The trait is an attempt to allow the deserializer to be "introspected" before a serde::Deserialize::deserialize function implementation actually uses the deserializer. Totally untested at the moment!
bassmanitram
changed the title
bassmanitram
changed the title
|
Ok, that's totally untested at the moment, but compiles and passes clippy. My use case compiles fine - too late to test now, on it in the morning |
The "into_tape" and reconstruction of the Deserializer after is far easier to manage than all the lifetime stuff that gets involved when borrowing from the deserializer, so that is what the extension trait now publishes - and my use case compiles with it, even if it hasn't yet been tested.
|
You live and learn eh - can't "specialize", it seems - the default implementation is always invoked! |
|
OK, lets try a deserializer for Node ... which of course means I have to start hacking another of your libraries - value_trait :) |
|
Nope - that's fantastically complex too, it seems! This is becoming soul destroying! |
bassmanitram
changed the title
|
Just a few thought experiments would any of the following work:
Or: adding a |
|
OK, I leave this here - serde::de::DeserializeSeed "solves" the issue, but where I'm trying to implement it has serde_json so ingrained that swapping over to simd_json (with necessary "unsafe" stuff too) is just too onerous at the moment. So the PR with only from_tape is ready, and some kind of solution to RawValue would be appreciated in the future. |
Rebase failed
|
I manually merged this to avoid the conflicts :) thank you! |
Issue #365
from_tapemethod on the Deserializer allows a tape to be extracted from a Deserializer viainto_tapeand then be used to rebuild a Deserializer. It is marked asunsafebecause no structure verification is performed - it is up to the caller to make sure that the tape is correct (e.g. by extracting from a Deserializer, performing read-only operations, then rebuilding a Deserializer).At the moment, however, nothing I try is able to allow access to that from within a standard serde::Deserializer.