You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Some users want to either auto-generate #[derive(...)] attributes (e.g. for use with bindgen) or use a single macro to generate all types uniformly (e.g. libc (#557)). Having to manually maintain different derives for different types (e.g. when some types are IntoBytes but others aren't) is very laborious.
Instead, we could support a mode in which a failure simply causes zerocopy-derive to not emit a trait impl, but does not cause compilation failure:
In this example, IntoBytes, TryFromBytes, and FromZeros impls would be emitted, but a FromBytes impl would not.
For errors emitted by our derive code, this is doable and straightforward. For errors emitted when trying to compile code emitted by our derive code, we'll require the trivial_bounds feature to be stabilized.
As described in #712 (comment), users may also want this in "normal" code (rather than macro- or bindgen-generated code), in which case they may want to assure that certain traits are implemented. It would be bad UX if they simply discovered later that a particular bound wasn't satisfied. Perhaps we could support an attribute that specifies which traits should be treated like normal, and which should be treated silently:
Some users want to either auto-generate
#[derive(...)]
attributes (e.g. for use with bindgen) or use a single macro to generate all types uniformly (e.g. libc (#557)). Having to manually maintain different derives for different types (e.g. when some types areIntoBytes
but others aren't) is very laborious.Instead, we could support a mode in which a failure simply causes zerocopy-derive to not emit a trait impl, but does not cause compilation failure:
In this example,
IntoBytes
,TryFromBytes
, andFromZeros
impls would be emitted, but aFromBytes
impl would not.For errors emitted by our derive code, this is doable and straightforward. For errors emitted when trying to compile code emitted by our derive code, we'll require the trivial_bounds feature to be stabilized.
As described in #712 (comment), users may also want this in "normal" code (rather than macro- or bindgen-generated code), in which case they may want to assure that certain traits are implemented. It would be bad UX if they simply discovered later that a particular bound wasn't satisfied. Perhaps we could support an attribute that specifies which traits should be treated like normal, and which should be treated silently:
The text was updated successfully, but these errors were encountered: