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
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.
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.
The text was updated successfully, but these errors were encountered:
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.
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 newNoCell
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:
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 ofAllTraits
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)
implyingderive(FromZeros)
, this is less of an issue sinceFromBytes: FromZeros
means that you must deriveFromZeros
in order to deriveFromBytes
, so it doesn't really matter whether the error technically comes from the derive ofFromZeros
or from the derive ofFromBytes
. By contrast, a user encountering an error fromAllTraits
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.The text was updated successfully, but these errors were encountered: