nanoserde icon indicating copy to clipboard operation
nanoserde copied to clipboard

add serialize_with and deserialize_with attribute families for json/bin

Open Adjective-Object opened this issue 1 year ago • 3 comments

This change adds support for nanoserde's analogs for serde's serialize_with and deserialize_with field attributes.

nanoserde is designed to translate directly between the serialized format the in-memory representation. This requires splitting the attribute into separate attributes for each of the target formats, instead of the singular deserialize_with or serialize_with.


For context, I'm porting a library from serde to nanoserde to try to reduce binary size in a game I'm working on, and to facilitate that, I found it handy to bridge some of the feature gap between the libraries.
Let me know if you're okay with contributions in this vein. I generally like to upstream new features when maintainers are interested.

Adjective-Object avatar Oct 04 '24 03:10 Adjective-Object

To preface this comment, note that I did not dig deep enough and I might not understand certain details.

But my first thought: would it be possible to use a proxy type with custom DeJson implementation to achieve the same result?

not-fl3 avatar Oct 04 '24 05:10 not-fl3

would it be possible to use a proxy type with custom DeJson implementation to achieve the same result

I am think that would work. I'm not 100% sure, but I think that incurs an extra copy from the deserialized proxy into the field, unless the proxy type has the exact same memory layout as the target type.

For clarity, are you saying that the library consumer should use proxy type, or that any deserialize_with attribute would generate a proxy struct to deserialize with?

Adjective-Object avatar Oct 04 '24 19:10 Adjective-Object

I would at least try to implement the same tests with the proxy on the user level. Generally, I would usually choose slightly less user-space ergonomics for less implementation complexity, but it really depends on how much worth for the user, how much more complexity etc etc.

But I do not have any strong opinion on this yet, I am not saying that we should not have serialize_with!

not-fl3 avatar Oct 04 '24 20:10 not-fl3