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

Allow deriving all traits using a single derive #712

Open
joshlf opened this issue Dec 10, 2023 · 1 comment
Open

Allow deriving all traits using a single derive #712

joshlf opened this issue Dec 10, 2023 · 1 comment
Labels
compatibility-nonbreaking Changes that are (likely to be) non-breaking

Comments

@joshlf
Copy link
Member

joshlf commented Dec 10, 2023

I recently spent multiple hours upgrading Fuchsia's vendored zerocopy to 0.8.0-alpha.1. The vast majority of this effort was spent updating #[derive(...)] annotations to also derive our new NoCell trait.

The vast majority of types I encountered could soundly implement all of zerocopy's current traits, and could also soundly implement future planned traits such as TryFromBytes. For these types, if there had been an "alias" that represented "all of zerocopy's traits", it would have saved me a huge amount of time. For the small subset of types which could not support this, still listing traits manually would be trivial.

I'm thinking something like:

#[deive(zerocopy::AllTraits)]
#[repr(C)]
struct Foo { ... }

The main drawback of this approach is that it's only forwards-compatible with adding new traits when those traits are guaranteed to be derivable on all types for which the old set of traits was derivable. We may end up in a situation where, within a given version train, we have to add a trait that one would reasonably expect to be implied by AllTraits, but cannot be until the next version train. That might not be the worst thing, since the main benefit of AllTraits is in making semver-breaking upgrades lower-friction. It would mean that, when performing a semver-breaking upgrade, derives would mostly continue to just work with the exception of newly-added traits that aren't backwards-compatible.

Another question to consider is whether error messages will be easy to understand. It may be the case that it would be unclear which trait is generating a particular error message. For situations like derive(FromBytes) implying derive(FromZeros), this is less of an issue since FromBytes: FromZeros means that you must derive FromZeros in order to derive FromBytes, so it doesn't really matter whether the error technically comes from the derive of FromZeros or from the derive of FromBytes. By contrast, a user encountering an error from AllTraits will likely want to understand which trait is causing the problem, and then replace the derive with a derive of all but the offending trait.

@joshlf joshlf added the compatibility-nonbreaking Changes that are (likely to be) non-breaking label Dec 10, 2023
@joshlf
Copy link
Member Author

joshlf commented Sep 27, 2024

If we implemented #1769, that could permit us to support #[derive(zerocopy::AllTraits)] in a forwards-compatible way. In particular, AllTraits could be configured to always use "silent failure" mode so that if we were to add new traits and update AllTraits to imply these new traits, that would not be a breaking change.

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