Our MapAccess needs to know both the K and the V when doing stuff, and cannot work if either is unknown. This is purely because you can't "cancel" a successful next_key_seed. Anyway would it be too upsetting if we made next_key_seed and next_value_seed unimplemented!() and only supported next_entry_seed?
Could you provide more context? What crate are you working with? What are
next_entry_seed? Right now it's hard to tell what you're talking about, for me at least.
If you're talking about in
serde, it seems unlikely.
next_value_seed are required methods of the
MapAccess trait. If you don't implement them then I suspect your implementation won't work with most
Deserializers since they would be written assuming those methods exist. That said, you could always try it and do thorough testing for your particular use case to see if it works.
Yes, serde. It should work for BTreeMap/HashMap at least... those use next_entry_seed/next_entry.
I guess thats right that it would be the
Deserialize impls that would be the ones calling
next_key_seed and the like. Just looking around, things like
serde_json::Value seem to use
next_key_seed and there is at least some sort of derive implementation in
serde that uses it. I think in this case if you really can't implement those two functions (though i think you probably could by having the deserializer temporarily store values that it retrieves that are not keys or values), I would make sure to have tests for deserialization of all the types you expect to see to avoid unexpected surprises down the line.
We really can't because we need to see both the key and its corresponding value to be able to decide whether to return a given key or not.
next_key_seed only sees the key. it only gets the type of the key. it doesn't let you see the value.
This topic was automatically closed 90 days after the last reply. We invite you to open a new topic if you have further questions or comments.