std.random suggestions

[Denis Feklushkin]

On Sunday, 21 September 2025 at 21:44:54 UTC, 0xEAB wrote:
> On Tuesday, 16 September 2025 at 12:04:20 UTC, Denis Feklushkin 
> wrote:
>> No need to make ambitious interfaces
>
> `std.internal.entropy` an internal module — not meant for user 
> code.
> From a user’s perspective, there is nothing to interface with.

Yes. But I wrote this because I realized that access to 
`getentropy` and `getrandom` (here I mean system-independed 
analogs) is absolutely necessary and actually it is already 
implemented in `std.internal.entropy`

Otherwise, for example, if we want to generate 3 bytes of random 
numbers from freshly created `Ranadom()` we spent at least 4 
bytes of expensive "true entropy" to establish our own PRNG, 
which we also declared as cryptographically insecure.

It's much easier and not error prone to directly access the 
system RNG or create our own generator with implicit global seed 
value (if system not provides CSPRNG for us). This will 
immediately make it possible to obtain crypto-secure random 
numbers.

>> 1. Do not provide any access about entropy sources (I am about 
>> std.internal.entropy.EntropySource.tryAll and 
>> forceEntropySource). At the application programming level we 
>> usually have one source of true entropy. (If this is not so
>
> `tryAll` in particular exists so that the module can be used in 
> a backwards compatible manner to replace the low entropy 
> solutions previously used underneath by Phobos. We’ve tried 
> replacing them with one solution per platform directly and 
> people got upset.

At the coding stage we know exactly what quality of random 
numbers we are agreed at this particular code point: maybe, 
people got upset because they actually wanted crypto-secure 
randoms? And if `std.random` returning the same sequence every 
time it's launched (I'm not even talking about cryptographic 
security), then this is most likely not what they want.

We could further add methods I suggested so that the user knows 
exactly what quality of random numbers they'll obtain. And then 
old interface can be deprecated over time.

>> At the application programming level we usually have one 
>> source of true entropy.
>
> At Phobos v2 level, we have no source of true entropy. An 
> application using only that library has therefore none.

(But, in fact, for most modern systems we are calling 
`getentropy` inside of Phobos `std.internal.entropy`)

> At system level, there might be multiple options available — 
> depending on factors like the OS version (like Linux kernels 
> older than the `getrandom` syscall, or Windows that has two 
> crypto APIs where the supported parameters have also changed 
> over time) or the runtime environment (think of chroots without 
> `/dev/`).

Yes, I mentioned this: if TRNG isn't available, proposed 
functions simply won't be available. So user will either be 
forced to agree insecure pseudo-random sequences or be forced to 
find another way to achieve randomness.