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

Make as much of zerocopy as possible work in a const context #115

Open
joshlf opened this issue Nov 2, 2022 · 0 comments
Open

Make as much of zerocopy as possible work in a const context #115

joshlf opened this issue Nov 2, 2022 · 0 comments
Labels
compatibility-nonbreaking Changes that are (likely to be) non-breaking

Comments

@joshlf
Copy link
Member

joshlf commented Nov 2, 2022

Currently, most of zerocopy's abstractions don't work in a const context for one reason or another. We should change that as much as possible.

This is a blocker for ICU4X using zerocopy.

Trait methods

One large subset of the API is the set of trait methods. Most or all of these don't rely on calling other trait methods, but effectively just use the trait bound to guarantee that the operation is sound. This entire subset in principle ought to be representable as bare functions, and many of them would likely be convertible into const fns. We could of course keep the trait methods as well, and just implement them in terms of the functions.

This approach has two big downsides:

  • It would effectively duplicate a large subset of our API surface
  • We would probably want to remove the bare functions in a future release once all of the trait methods could themselves be const (it's not clear to me how far off this is)

TryFromBytes

Our derive for TryFromBytes automatically derives the is_bit_valid method. In order to support const TryFromBytes, we would need to:

  • Emit an inherent #[doc(hidden)] pub fn __zerocopy_is_bit_valid(...) -> bool
  • Rewrite our impl of TryFromBytes::is_bit_valid to call this function
  • Possibly provide an attribute to allow renaming that function for macro hygiene reasons
    • Note: It's unclear whether this would work at all since other const code needs to be able to call the function at a well-known name
  • If it doesn't work on our MSRV, we could just make it an optional zerocopy-derive feature (which is exposed via zerocopy with a feature of the same or similar name)

Note a very fundamental limitation: There would be no way to support generic types (e.g., #[derive(TryFromBytes)] struct Foo<T>(T)) because the only way to invoke the function would be to name the type it operates on (e.g., Foo::__zerocopy_is_bit_valid(...)). This also means that the public API would need to be a macro in order to emit the appropriate code.

@joshlf joshlf added the compatibility-nonbreaking Changes that are (likely to be) non-breaking label Aug 12, 2023
@joshlf joshlf mentioned this issue Aug 20, 2023
This was referenced Mar 1, 2024
@joshlf joshlf mentioned this issue May 3, 2024
87 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility-nonbreaking Changes that are (likely to be) non-breaking
Projects
None yet
Development

No branches or pull requests

1 participant