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 types satisfy the soundness requirements of our traits, but nonetheless have a safety invariant that means that it would be invalid for them to expose the ability to do things like construct arbitrary instances of their type. E.g.:
/// An unforgeable token that represents that an operation has been performed.#[repr(transparent)]pubstructCompletionToken(());
(Okay, this type probably wouldn't be #[repr(transparent)], but you get the point.)
This has two implications:
We can't write blanket impls for types based on their layout even if it would be sound. E.g., if we're able to encode ZST-ness in the type system, it would still be invalid to implement FromBytes for any ZST type despite it being technically sound.
We should clarify in the trait documentation what the author is opting into by deriving or implementing these traits. For TryFromBytes, we should also call out the interaction with custom validation.
The text was updated successfully, but these errors were encountered:
See also: #1792 (comment)
Some types satisfy the soundness requirements of our traits, but nonetheless have a safety invariant that means that it would be invalid for them to expose the ability to do things like construct arbitrary instances of their type. E.g.:
(Okay, this type probably wouldn't be
#[repr(transparent)]
, but you get the point.)This has two implications:
FromBytes
for any ZST type despite it being technically sound.TryFromBytes
, we should also call out the interaction with custom validation.The text was updated successfully, but these errors were encountered: