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

Someday Maybe #1120

Open
2 of 34 tasks
joshlf opened this issue Apr 18, 2024 · 0 comments
Open
2 of 34 tasks

Someday Maybe #1120

joshlf opened this issue Apr 18, 2024 · 0 comments

Comments

@joshlf
Copy link
Member

joshlf commented Apr 18, 2024

This issue tracks ideas which we might want to tackle some day, but which don't have enough detail to warrant their own separate issues.

Feature additions

  • Track all parser ideas somewhere in the zerocopy repo, including this prototype; also link to Support mid-level byte slice and buffer operations #1315
  • If two slice DSTs have the same slice offset, element size, and alignment, then we can support transmute_ref! and transmute_mut! for these types - just need to figure out how to encode all of these in the type system (e.g. associated types on KnownLayout)
  • As part of a broader trend towards teaching zerocopy to express more powerful transmutations, could we add trait AsInitialized<T>? We could use it to replace the existing Src: IntoBytes bound in transmute!, try_transmute!, etc
  • Look at the nolife crate's API for inspiration
  • Look at the binary_layout crate's API for inspiration
  • Add method to Ref to change the type parameter (ie, perform a transmutation); we could use this to make new_sized a thin wrapper around new
  • Support stdlib's new generic NonZero<T>
  • Support transmuting T to MaybeUninit<T> (or maybe even MaybeUninit<U>) even when T: ?IntoBytes
  • Once generic_const_exprs and associated_const_equality are stabilized, we can use KnownLayout::LAYOUT to guarantee layout equality, supporting both size equality and slice DST equality (e.g., T: KnownLayout, U: KnownLayout<LAYOUT = {T::LAYOUT}>); see playground example

Safety

Performance

Developer experience

  • Consider using cargo nextest to speed up CI execution times
  • Cargo docs published to google.github.io/zerocopy could include link to the commit that generated it
    • One idea for how to do this: programmatically edit the crate-root doc comment with a link
    • Maybe publish each commit's docs in a subdirectory named for that commit's hash so we have a historical record of all documentation?
  • Publish cargo docs to google.github.io/zerocopy for every PR (see this StackOverflow question)
  • Consider using cargo release
  • Consider using larger GitHub Actions runners
  • In CI, confirm that MSRV is lower than any version we use for version detection. This will naturally trigger us to clean up the codebase when we bump MSRV.

Documentation

  • Write documentation post on zerocopy's values
  • Be consistent about our use of "interpret" vs "reinterpret" in doc comments
  • Compile for multiple targets on docs.rs using the package.metadata.docs.rs.targets Cargo.toml key (see e.g. usage in syn)?

Testing

Miscellaneous

Done

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

1 participant