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

Add FromBytes::getrandom method #814

Open
wants to merge 3 commits into
base: main
Choose a base branch
from
Open

Conversation

newpavlov
Copy link
Contributor

The method is gated on the disabled by default getrandom feature.

This PR is an alternative to rust-random/getrandom#381.

Reasons for why it could be better to add this method to zerocopy instead of introducing the getrandom::value function:

  • getrandom has lower MSRV than zerocopy.
  • getrandom does not have plans for breaking releases in the near future, while zerocopy has.
  • It allows to generate values using a bit nicer u32::getrandom(), while getrandom::value() may require explicit type ascription.
  • zerocopy looks like a better place for keeping unsafe code for transforming (random) bytes to a value of FromBytes type.
  • If we are to give up on returning getrandom::Error, zerocopy will not have any types from getrandom in its public API, while getrandom would always rely on FromBytes bound in its public API.

@newpavlov newpavlov changed the title Add FromBytes::getrandom method gated Add FromBytes::getrandom method Jan 24, 2024
@newpavlov
Copy link
Contributor Author

@joshlf
Could you give feedback on this addition?

@joshlf
Copy link
Member

joshlf commented Feb 21, 2024

Apologies for the radio silence.

Right now all of our effort is going into #671. At some point we do want to figure out a unified strategy for how to support integrations with other crates, but we're not going to have the cycles to do that work until 0.8 has been released. This PR on its own is obviously reasonable, but we want to be careful about how to expose APIs like these so we don't lock ourselves into supporting API patterns that we later want to walk back, and so we want to make sure we've thought through the whole design space before we publish even a simple API like this one.

TLDR: We're interested in something like this, but it will likely be quite some time before we are able to move forward on it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants