Towards rand 1.0

[dhardy]

We've had questions about when Rand will reach 1.0. We're not there yet, but it is still worth discussing the dependency on getrandom.

From memory & quick skim the only part of the API which is affected by getrandom is rand_core::Error, and only in two ways:

• The declared constants must match those in getrandom::Error. This doesn't really require getrandom to be 1.0 so long as there is a stability promise affecting these.
• impl From<getrandom::Error> for Error, which thus pins rand_core to a single getrandom major-minor version.

Potential solutions:

1. Stabilise getrandom 1.0 soon? Seems unlikely?
2. A separate crate just for Error — perhaps viable but definitely not desirable
3. Use the promise above and deprecate that impl, forcing users to rely on getrandom::Error::code() -> NonZeroU32 and impl From<NonZeroU32> for Error

CC @vks @newpavlov

[gilescope]

That error code looks a little like an enum with non-exhaustive on it?

[vks]

I think the most important part of our API affected by getrandom is actually SeedableRng::from_entropy.

Why is stabilizing getrandom 1.0 unlikely?

[dhardy]

from_entropy and OsRng are not re-exporting any getrandom symbols. They use it internally, but that's fine because bumping the getrandom version inside a patch-release of rand_core won't cause problems there — but it can with that From<getrandom::Error> impl.

That error code looks a little like an enum with non-exhaustive on it?

Essentially, yes. But one that's user-extensible (e.g. by a custom backend) without any crate dependencies. Go read #3.

[gilescope]

Thx for that history pointer. A stability promise on the existing constants seems pretty uncontroversial? New ones could still be added...

[josephlr]

As one of the maintainers, I would be fine committing to stability for the numerical constants. Specifically something like "these constants will not change between now and 1.0", and we could put something like that in the README.

I think the most important part of our API affected by getrandom is actually SeedableRng::from_entropy.

While this is true, it should be possible to have that API be stabilized without getrandom necessarily being in 1.0. For example if getrandom's API changed (not that we really anticipate such a thing), you would just need a way to still implement from_entropy with the new API.

I think removing the impl From<getrandom::Error> for Error would be wise, as it seems redundant to have that impl and impl From<NonZeroU32> for Error

Why is stabilizing getrandom 1.0 unlikely?

Personally, I don't think it's too unlikely, I would just want to resolve some outstanding issues before doing so. Specifically:

• I would want to get consensus on if we need any backwards incompatible changes for @briansmith's issues
  • Issues are Expose API interface for MaybeUninit<u8> slice #226, Document how the fallback to File I/O works regarding file handle usage and sandboxing #227, RDRAND-based output is (too) biased #228, Should getrandom() really fall back to File I/O when the getrandom syscall returns EPERM? #229, It should be possible to use a custom implementation when RDRAND is available #230
  • Basically, I want a getrandom 1.0 that is compatible with use by ring.
  • Whether ring ends up actually using getrandom is a different issue (and shouldn't block stabilization).
• Responding to the review by @m-ou-se in The getrandom crate m-ou-se/getrandom#1
  • Most of the suggestions seem reasonable, I just need time to start on implementation
• Getting getrandom usage adopted by libstd
  • Tracked in Use getrandom for generating HashMap seed rust-lang/rust#80149
  • Blocked by Use BCryptGenRandom instead of RtlGenRandom on Windows. rust-lang/rust#84096

[newpavlov]

Also ideally before releasing 1.0 I think it's worth to have MSRV-dependent dependency version resolution implemented in Cargo, so it would be possible to bump MSRV without breaking builds on older toolchains.

[gilescope]

Great work that's being done pushing this all forward. Mouse's review seemed very positive. Let me know if I can help in any way.

[newpavlov]

As proposed here, another potential API change for 1.0 is to use BorrowedBuf instead of &mut [MaybeUninit<u8>] for getrandom_uninit.

[briansmith]

As proposed #485 (comment), another potential API change for 1.0 is to use BorrowedBuf instead of &mut [MaybeUninit] for getrandom_uninit.

I don't know if it would make sense to change the public API to use BorrowedBuf/Cursor. I was suggesting there it might make sense to change the internal ones like sys_fill_exact. Even then I'm not sure.

[newpavlov]

I think we can close this issue for now since most of the discussion is no longer relevant.

Before considering v1.0 we need to get some experience with getrandom v0.3. There is also a possibility of std introducing a getrandom-like API (see rust-lang/rust#130703) which would make this crate obsolete.

When it will be the time for rand v1.0 release we can open a new issue to consider whether we should release getrandom v1.0 or not.