std.random suggestions

[Denis Feklushkin]

On Wednesday, 17 September 2025 at 09:00:44 UTC, Dmitry Olshansky 
wrote:
> On Tuesday, 16 September 2025 at 12:04:20 UTC, Denis Feklushkin 
> wrote:
>> I don't like the way the module std.random is designed
>>
>> From a software side we have three types of ~random numbers 
>> sources:
>
>> That's all, and nothing superfluous! I.e., if you do not use 
>> something, it does not creates any global variables, etc. From 
>> the point of view of the user, seems, everything is also 
>> simple and clear. It will be difficult to make a issue with 
>> RNG in this case.
>>
>> Perhaps this is suitable for Phobos 3?
>
> To be honest this seems like a major overengineering.

Nope, this is a statement of the factual situation on 2025. All 
these things are already implemented inside of `std.random` and 
`std.internal.entropy` whether you want it or not.

At the same time, with all the current overengineered(!) code you 
can't take 256 bit seed at all. (This size, as far as I know, is 
the recommended seed size for now.)

> It’s a given in a whole lot of languages that random means PRNG 
> with optional seed. The seed could be obtained via some 
> function to be largely unpredictable, with the benefit that you 
> could replay the program with a particular seed to ease 
> debugging / fuzzing etc.

Let me repeat a good example of an issue due to current 
`std.random` overcomplication: 
https://github.com/dlang/phobos/pull/10865

This wouldn't happen if we simply provided a function that would 
simply return a random buffer.

> Now of hardware sources most language would provide 
> CryptoRandom which takes the bits from whatever deemed as 
> secure source of random bits, most likely get_random or 
> /dev/urandom (yes it is fine for generating keys, check the 
> literature). Everything else is plain overengineering and 
> deserves to be written in 3rd party library by these willing to 
> pursue it.

Copied from 
https://github.com/dlang/PhobosV3-Design/discussions/42#discussioncomment-14426280 :

I think the opposite:

OS can have any (proprietary) patch/module/driver about random 
and urandom sources. Architecture-independent standard library 
should not rely at all for a specific operating system internals. 
So we need an architecture-independent library that should take 
random/urandom difference into account

And it is also need to understand that declaring of abandoning 
cryptographic quality of randoms in 2025 is nonsense!

We have plenty of everyday applications of real true random 
numbers now. Distributed computend relies to them (see UUIDv7). 
TRNG generators have been built into all modern CPUs for 10 years 
now.