-
Notifications
You must be signed in to change notification settings - Fork 131
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Can't handle #[serde(tag = "someKey")] for structure while Deserialization #318
Comments
Default encoding doesn't keep field names, so it's unable to know which field was the tag field. If you use |
Here is a more minimalist reproduction of this issue - https://github.com/e-ivkov/rmp-bug-repro I understand that this is not directly a bug, but I would call it an interface inconsistency. It is natural to expect, that if something serialized successfully, it will also de-serialize back. All other serde libraries behave like that. I would suggest to always use named serialization in |
It looks like there are hard trade offs here, as some people want the efficient representation. |
Just seconding the view that the interface inconsistency is actually broken. Anything that can be serialized should successfully deserialize, and vice-versa. I'm all for stripping names unless opted-in, but that doesn't justify self-inconsistent code. Does this need a from_slice_named() so that it has to be explicit on both sides? The current behavior is just straight broken. |
Serde doesn't tell the serialiser about existence of any extra options, so at serialisation time there's no way to know if the name is going to be necessary to deserialise or not. So unfortunately it's up to the user to choose named serialisation if they rely on it. |
Here is error I am getting:
There is no problem with
serializing
anddeserializing
withserde
. Withrmp_serde
there is no problem inserializing
astruct
with a given tag but while deserializing it is not able to taketag
provided as key and giving length error.The text was updated successfully, but these errors were encountered: