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

skip_serializing_if is a footgun #1732

Closed
khuey opened this issue Jan 31, 2020 · 5 comments
Closed

skip_serializing_if is a footgun #1732

khuey opened this issue Jan 31, 2020 · 5 comments

Comments

@khuey
Copy link
Contributor

khuey commented Jan 31, 2020

skip_serializing_if only works if the serialization format is self-describing. It does not work with e.g. bincode. This is a footgun in a codebase that uses more than one serialization format at different points, because I can add skip_serializing_if to something that gets fed into the JSON serializer and it works fine, but when it gets fed into the bincode serializer it produces garbage that will fail to deserialize.

I think the solution here is for Serializers to declare whether or not they support skipping things and then make skip_serializing_if only have an effect for serializers that can tolerate it.

@dtolnay
Copy link
Member

dtolnay commented Jul 5, 2020

I think I would prefer not to build an additional toggle into the Serializer API for this.

This is a subissue of a limitation that data structures which need to follow a different codepath for serializing to different formats are not well supported by serde.

@sffc
Copy link

sffc commented Oct 13, 2020

The lack of this feature causes problems when building serializable data structures to work with an arbitrary serializer. We have to feature-gate our code to disable skip_serializing_if on the "bincode" feature, which is really awkward.

@Manishearth
Copy link
Contributor

What if skip_field were still passed the field so that the serializer can decide to serialize it anyway?

@Manishearth
Copy link
Contributor

Filed #2012 for that idea

@khuey
Copy link
Contributor Author

khuey commented Oct 10, 2021

This continues to be a source of woe.

@serde-rs serde-rs locked and limited conversation to collaborators Jan 23, 2022
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

4 participants