[API Proposal]: System.Random.NextUInt64

[VesperGarment]

Background and motivation

Could we add System.Random.NextUInt64() ? As far as I can tell the only way to get a UInt64 full of random bits is to use Random.NextBytes() to get 8 bytes and the BitConverter them. This feels kind of icky because the implementation appears to be based on getting a UInt64 at a time - everything else is written in terms of it. So having to call it through coded that checks sizes and spans and such is kind of silly.

API Proposal

namespace System;

public class Random
{
    public virtual ulong NextUInt64() { // no need to bother with minValue and maxValue.
        return _impl.NextUInt64();
    }
}

API Usage

// I believe this would then be the "best" way to generate a random bool (as the core random work gets a ulong at a time).

bool NextBool(this Random rnd) {
    var u = Random.Shared.NextUInt64();
    return u & 1 == 1;
}


### Alternative Designs

_No response_

### Risks

I can't really think of any. Perhaps would become less "correct" if underlying implementation ever changed to not be 64-bit word based. But that seems unlikely?

[VesperGarment]

I've also seen places where people get a random UInt64 via unchecked((UInt64)r.NextInt64()) without realizing that they're only getting 63 bits of random (as NextInt64 only gives positive values). It'd be nice for the API to steer people out of that (admittedly probably not much of a problem) mistake.

[elgonzo]

As far as I can tell the only way to get a UInt64 full of random bits is to use Random.NextBytes() to get 8 bytes and the BitConverter them. This feels kind of icky because the implementation appears to be based on getting a UInt64 at a time - everything else is written in terms of it. So having to call it through coded that checks sizes and spans and such is kind of silly.

You don't really need to do laborious workarounds to get 64 random bits. There is the NextInt64(Int64, Int64) overload that is able to produce negative values. Technically, you will only ever get at most 2^64-1 different values from the 64-bit value range with NextInt64, because the parameter for the max value is an exclusive upper bound. So, NextInt64(long.MinValue, long.MaxValue) will give you 64 bits worth of randomness (including negative values), with the one caveat that it will never produce the value long.MaxValue (the exclusive upper bound). The NextInt64 method overloads are basically the 64-bit equivalent to the 32-bit Next method overloads.

(My comment here is not an argument pro or contra your API proposal. It's just meant as a clarification to what appears to me as you missing to notice the NextInt64(Int64, Int64) overload.)

[tannergooding]

If this were to be provided, it is likely that NextUInt32() should also be considered at a minimum.

It's possible that other convenience helpers should also be provided for built-in primitive integral types such as NextByte, NextSByte, NextInt16, and NextUInt16.

Providing a general purpose Next<TInteger>() is likely not super feasible, however. There's potentially some things that could be done, but I don't think the API surface would be very "nice".

CC. @stephentoub, @GrabYourPitchforks for secondary thoughts; but I think at least NextUInt32/64 is a small and reasonable improvement that reduces risk for the scenarios that may need it.

[Clockwork-Muse]

... the current implementation for unseeded Randoms has a slightly biased implementation of NextBytes...