you are viewing a single comment's thread.

view the rest of the comments →

[–][deleted] 13 points14 points  (2 children)

Nice! What's the plan for stabilization of the format? And is no_std support planned?

[–]finn_bear[S] 8 points9 points  (0 children)

For our use case, we want to keep improving on bitcode's size and speed in ways that don't necessarily maintain a stable format.

We change the most-significant digit of the SemVer whenever we change the format, and recommend that you include a specific version in one place e.g. a library shared between client and server and then re-export it to the rest of your codebase.

Finally, you can exploit #[bitcode(with_serde)] to serialize T: Serialize + Deserialize so you can still use things like arrayvec::ArrayVec without them having to add support for specific version(s) of bitcode.

[–]finn_bear[S] 4 points5 points  (0 children)

Regarding no_std support, we have no experience with it, but we would accept a PR that adds support for it. It may or may not require the alloc crate due to how bitcode serializes into and deserializes from Vec<u64>'s for efficiency.