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

Document that our traits opt-in to creating type instances #260

Open
joshlf opened this issue Aug 14, 2023 · 0 comments
Open

Document that our traits opt-in to creating type instances #260

joshlf opened this issue Aug 14, 2023 · 0 comments
Labels
compatibility-nonbreaking Changes that are (likely to be) non-breaking

Comments

@joshlf
Copy link
Member

joshlf commented Aug 14, 2023

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.
@joshlf joshlf added blocking-next-release This issue should be resolved before we release on crates.io compatibility-nonbreaking Changes that are (likely to be) non-breaking labels Aug 14, 2023
@joshlf joshlf mentioned this issue Aug 20, 2023
@joshlf joshlf removed the blocking-next-release This issue should be resolved before we release on crates.io label Sep 3, 2023
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