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

Make getrandom a non-pub dep; rename feature to os_rng #1537

Merged
merged 10 commits into from
Nov 26, 2024

Conversation

dhardy
Copy link
Member

@dhardy dhardy commented Nov 25, 2024

  • Added a CHANGELOG.md entry

Remove getrandom from the public API so that upgrading the version used will be non-breaking.

Rename the feature getrandom to os_rng. This is in line with small_rng, std_rng, and its effect of enabling OsRng, from_os_rng and rand::rng.

@dhardy dhardy requested review from newpavlov and josephlr November 25, 2024 13:29
Copy link
Member

@newpavlov newpavlov left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think getrandom::Error can be still exposed in the public API of rand_core. I don't think it's worth to wrap it in a custom type at this stage.

@dhardy
Copy link
Member Author

dhardy commented Nov 25, 2024

I think getrandom::Error can be still exposed in the public API of rand_core. I don't think it's worth to wrap it in a custom type at this stage.

I disagree: getrandom is an implementation detail that does not need to be exposed to the user. Bumping the getrandom version should not require a version bump to rand_core.

It is possible to add a method like fn as_getrandom_0_2(self) -> Option<getrandom::Error>, but it would need to be feature-gated behind a getrandom_0_2 feature I think. Or use an external crate which provides traits like raw-window-handle (but you still end up needing the version-specific feature in rand_core).

For now I'm not sure it's worth bothering with this however.

@newpavlov
Copy link
Member

I am fine with wrapping the error, it's just that I don't see much merit in it since it's unlikely that API of getrandom will evolve faster than API of rand. It would've been a different story if it was a rand v1.0 release.

@dhardy
Copy link
Member Author

dhardy commented Nov 25, 2024

It would've been a different story if it was a rand v1.0 release.

Pretty much all the changes I've been planning are already in master, so my plan is to essentially treat v0.9 as an extended Beta for v1.0.

Yes, there's #1261, but if any of that lands it's more likely to be in v2.0 or later. Much of it depends on future Rust features.

@dhardy dhardy merged commit 0ff946c into rust-random:master Nov 26, 2024
15 checks passed
dhardy added a commit to dhardy/rand that referenced this pull request Nov 26, 2024
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