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

feature request: Default value for fields && Ignore extra bytes #32

Closed
kdy1 opened this issue Aug 22, 2024 · 2 comments
Closed

feature request: Default value for fields && Ignore extra bytes #32

kdy1 opened this issue Aug 22, 2024 · 2 comments

Comments

@kdy1
Copy link

kdy1 commented Aug 22, 2024

Note: This is similar to #29

Hi. I'm the author of the SWC project. We currently use rkyv for Wasm plugins.
We pass serialized bytes to the Wasm plugin and deserialize them from the Wasm plugins, but it's not backward-compatible.

Most of the time, we need to add fields to existing types. I don't want it to be a breaking change.
Is it possible with bitcode?

I think what we need here is ignoring extra data (from a new version of host) and using a default value if when not existing

@finnbear
Copy link
Member

Hello!

we need to add fields to existing types. I don't want it to be a breaking change.
Is it possible with bitcode?

No, that will never be possible with bitcode::{Encode, Decode}. bitcode is not self-describing, at all. You would need some abstraction like encoding a HashMap<String, Field> or Vec<Field>. As an exception, you can add variants to the end of an enum if you use the serde version of bitcode.

I think what we need here is ignoring extra data (from a new version of host) and using a default value if when not existing

When the total encoded length doesn't match decoding expectations, that is a very good indication that the data is corrupted. It is not enough information to reconstruct which part of the data-structure is missing or extra. Your suggestion to use defaults would only work for the outer-most struct, which we don't have much motivation to optimize for at the expense of much more complexity.

Note: This is similar to #29

#29 is different because it deals with unconditionally ignoring fields when encoding/decoding.

@kdy1
Copy link
Author

kdy1 commented Aug 22, 2024

Thank you!

@kdy1 kdy1 closed this as not planned Won't fix, can't repro, duplicate, stale Aug 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants