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
Both the keys and corresponding values have to be stored in sorted order (as determined by strcmp), such that lookups can be made using binary search.
However, I don't think we should use serialize_seq instead, at least not by default. For one, that would totally lose the map-like representation in formats like JSON -- instead of an Object we would get an Array. It would also break compatibility to change the serialized format at all, as this is an ABI of sorts -- old clients would lose the ability to read newly serialized maps. (It's possible to make new clients understand it either way.)
Maybe we could offer ordered helper functions instead, the same way we did "untagged" support for Either. So we would add a module like serde_ordered that treats the map like a sequence, and this could be tagged on specific fields like #[serde(with = "indexmap::serde_ordered")].
IndexSet is already treated as a sequence, so we should be fine there.
When using
flexbuffers
the order ofIndexMap
is not restored on deserialize.I am not sure if this should be considered a bug in
flexbuffers
, a bug inindexmap
or a shortcoming ofserde
. The implementation ofserse::Serialize for IndexMap
usesserialize_map
which does not specify if the keys should keep the order.Maybe
IndexMap
should useserialize_seq
instead, i.e. encode a map as an array of key-value pairs?Related issues
google/flatbuffers#6120
Reproduce
with
indexmap = { version = "=1.6.0", features = ["serde-1"] }
:This fails with
The text was updated successfully, but these errors were encountered: