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
Some data formats (such as CBOR and Protobuf) use types other than strings for keys. Currently, serde only allows struct serialization to contain string values for keys which prohibits this use case.
Scope
We are only attempting to solve this problem for homogeneous keys.
Proposed Solution
Other than adding an attribute (e.g. key = 1), the main concern comes from the signature of SerializeStruct::serialize_field which doesn't allow generics. Deserialization is trivial as it already uses MapAccess for deserializing which takes generics.
The solution we propose is adding the following methods to the SerializeMap trait:
Why #[serde(key = )] and not just extending #[serde(rename = …)] like #2209?
Good question! Perhaps because I didn't see that PR :D
It's probably better to use a new key though because it's often the case that self-describing formats still want the string key over the binary key. This wasn't implemented in my implementation, but it was something I came across while production testing this feature.
One reason in favor of rename for integer keys is for enums, where even in JSON an integer or a boolean can work: #2525
The advantage of using rename is that the interaction with alias is also pretty easy to understand (assuming that alias also supports non-string datatypes).
Some data formats (such as CBOR and Protobuf) use types other than strings for keys. Currently,
serde
only allows struct serialization to contain string values for keys which prohibits this use case.Scope
We are only attempting to solve this problem for homogeneous keys.
Proposed Solution
Other than adding an attribute (e.g.
key = 1
), the main concern comes from the signature ofSerializeStruct::serialize_field
which doesn't allow generics. Deserialization is trivial as it already usesMapAccess
for deserializing which takes generics.The solution we propose is adding the following methods to the
SerializeMap
trait:To make this non-breaking, the default implementation would just return
Ok(())
.The text was updated successfully, but these errors were encountered: