Skip to content
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

serde_derive guarantees are not documented #1756

Closed
ZoeyR opened this issue Mar 19, 2020 · 4 comments
Closed

serde_derive guarantees are not documented #1756

ZoeyR opened this issue Mar 19, 2020 · 4 comments

Comments

@ZoeyR
Copy link

ZoeyR commented Mar 19, 2020

I can't seem to find any documentation on any guarantees that serde_derive may have for the manner in which it serializes structs and enums. I'm mostly curious if the order in which it will call the different serialize_* and deserialize_* methods is guaranteed to be stable or not.

@dtolnay
Copy link
Member

dtolnay commented Jul 5, 2020

Or are they all documented, because there are none. ;)

Derived Serialize impls will call serialize_field according to the order of fields in the struct definition.

@ZoeyR
Copy link
Author

ZoeyR commented Jul 6, 2020

If there are actually no guarantees that would be good to know since formats that don't self-describe could potentially break based on serde_derive versions. serde_cbor in packed mode would also be affected since it uses indexes for the fields.

@ZoeyR
Copy link
Author

ZoeyR commented Sep 9, 2020

@dtolnay can you please clarify if serde_derive is guaranteed to call the fields in declaration order? If its just the current behavior and not actually part of the stability contract I need to know for documenting my format.

@dtolnay
Copy link
Member

dtolnay commented Sep 9, 2020

Yes, that can be considered stable.

@ZoeyR ZoeyR closed this as completed Sep 9, 2020
@serde-rs serde-rs locked and limited conversation to collaborators Oct 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Development

No branches or pull requests

2 participants