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.:

/// An unforgeable token that represents that an operation has been performed.
#[repr(transparent)]
pub struct CompletionToken(());

(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.