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

[joshlf]

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.

[kupiakos]

In theory (#239) transmute! etc. could be extended to work in const (and generic) contexts and to allow DST target transmutes to unblock many uses, including transmuting to [u8].

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)

It's fair to assume that features as big as const traits take years to stabilize (it's been 28 months after all 😄). While there is progress in 2025, I'd argue it's not particularly harmful to have a const module that is deprecated once const traits stabilize. This would reduce the currently-required unsafe that users must write.

[kupiakos]

In order to support const TryFromBytes, we would need to:

With some effort it would be possible to support TryFromBytes without any of this. The way to do this is by representing the type validity requirements in a struct which can be put in a const and then passed to a const fn checker function outside of the trait. Sample:

mod __internal {

pub struct ValidityInfo {
    validator: Validator,
    // building this in `const` in a macro without waste on every field is a fun challenge
    fields: &'static [FieldValidityInfo],
}

struct FieldValidityInfo {
    offset: usize,
    field_info: &'static ValidityInfo,
}

enum Validator {
    /* the hardest part to get right */
}

impl ValidityInfo {
    #[inline] // probably?
    pub const fn is_bit_valid(&self, bytes: &[u8]) -> bool { todo!() }
}

}

pub trait TryFromBytes {
    const VALIDITY_INFO: &'static ValidityInfo;
    ...
}