Skip to content

Someday Maybe #1120

@joshlf

Description

@joshlf

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
  • Add Unalign::replace or swap (which returns the original) and maybe deprecate Unalign::set. Strictly more powerful.

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.
  • Only generate roll PRs (for pinned stable and nightly toolchains) on week days
  • Allow setting repository-wide "vacation mode" that causes rollers to pause

Documentation

Testing

Community engagement and outside contributions

  • Post research projects on edu Zulip

Miscellaneous

Done

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions