On Tuesday, 16 September 2025 at 12:08:38 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 17/09/2025 12:04 AM, Denis Feklushkin wrote:
>> Perhaps this is suitable for Phobos 3?
>
> Not for V2.

There is also a suggestion to urgently fix problem with "true" random numbers in Phobos v2 right now: it is just need to extend `std.random.unpredictableSeed` template with template argument ubyte[]

Such patch will be accepted?

On Tuesday, 16 September 2025 at 18:10:22 UTC, Denis Feklushkin wrote:
> On Tuesday, 16 September 2025 at 18:04:20 UTC, Monkyyy wrote:
>> On Tuesday, 16 September 2025 at 12:04:20 UTC, Denis Feklushkin wrote:
>>> 2. Completely exclude "seeding" concept: this is a source of
>>
>> You can make it implict called, and leave the data public for whoever wants it.
>
> It is difficult to achieve this because in most cases it will be just a libc getrandom() call (system-wide seeded PRNG)

your suggested api does nothing for the majority of trivial randomness use cases

Video games, fuzzing, and algorithms uses of randomness can be both fairly cheap and in each I would want deterministic playback for when I need it. Access to the seed is nessery for many video game randomness hacks, and unit testing some random values is great and all but if you looking at a 1 in 100000 bug youd want to be able to hack in a reported seed for *when* it breaks, then speed testing randomness-using algorithms could want to redo tests as well if something seemed slow.

Fast randomness and secure randomness are different problems.

On Tue, Sep 16, 2025 at 06:59:01PM +0000, Denis Feklushkin via Digitalmars-d wrote:
> On Tuesday, 16 September 2025 at 12:08:38 UTC, Richard (Rikki) Andrew
> Cattermole wrote:
> > On 17/09/2025 12:04 AM, Denis Feklushkin wrote:
> > > Perhaps this is suitable for Phobos 3?
> > 
> > Not for V2.
> 
> There is also a suggestion to urgently fix problem with "true" random numbers in Phobos v2 right now: it is just need to extend `std.random.unpredictableSeed` template with template argument ubyte[]
> 
> Such patch will be accepted?

I'm not the one making decisions here, but from what I understand, std.random.unpredictableSeed is not meant to be a general interface for getting random bytes from the OS.  It's meant to be an abstraction for obtaining a (small) system-dependent value suitable for seeding pseudo-random generators like the ones you'd use for games or Monte Carlo simulations.  It just so happened that whoever implemented .unpredictableSeed decided to make use of OS random number APIs for obtaining this seed, but it was never meant for user code to call .unpredictableSeed as a source of random numbers.

If you want an API for getting random numbers from the OS, you probably need to propose a new module, or at the very least a new function in std.random.


T

-- 
People who are more than casually interested in computers should have at least some idea of what the underlying hardware is like. Otherwise the programs they write will be pretty weird. -- D. Knuth

On Tuesday, 16 September 2025 at 19:06:27 UTC, H. S. Teoh wrote:

> If you want an API for getting random numbers from the OS, you probably need to propose a new module, or at the very least a new function in std.random.

Technically, proposed new template will be a new function

It just doesn't make sense to duplicate (for the third time, probably) code that calls getrandom

On Tuesday, 16 September 2025 at 18:59:48 UTC, monkyyy wrote:
> On Tuesday, 16 September 2025 at 18:10:22 UTC, Denis Feklushkin wrote:
>> On Tuesday, 16 September 2025 at 18:04:20 UTC, Monkyyy wrote:
>>> On Tuesday, 16 September 2025 at 12:04:20 UTC, Denis Feklushkin wrote:
>>>> 2. Completely exclude "seeding" concept: this is a source of
>>>
>>> You can make it implict called, and leave the data public for whoever wants it.
>>
>> It is difficult to achieve this because in most cases it will be just a libc getrandom() call (system-wide seeded PRNG)
>
> your suggested api does nothing for the majority of trivial randomness use cases

I disagree.
I proposed major step forward for our ecosystem: you can just go and get 49 random bytes buffer. No seeding, no new calls to Random() (or genRnd?), etc. Just get a random sequence.

All sorts of whistles and bells can be screwed on top of this, if need.

For repeating sequences, I also proposed a solution.

And I am categorically against "universal solution" with classes, seed-accepting constructors, and all the other overengineering as we have now - even experienced people can't use it correctly, as practice shows. (I myself even remember using a third-party library to generate a random number because I was just too lazy to figure out the standard one.)

On Tuesday, 16 September 2025 at 19:25:58 UTC, Denis Feklushkin wrote:
> On Tuesday, 16 September 2025 at 18:59:48 UTC, monkyyy wrote:
>> On Tuesday, 16 September 2025 at 18:10:22 UTC, Denis Feklushkin wrote:
>>> On Tuesday, 16 September 2025 at 18:04:20 UTC, Monkyyy wrote:
>>>> On Tuesday, 16 September 2025 at 12:04:20 UTC, Denis Feklushkin wrote:
>>>>> 2. Completely exclude "seeding" concept: this is a source of
>>>>
>>>> You can make it implict called, and leave the data public for whoever wants it.
>>>
>>> It is difficult to achieve this because in most cases it will be just a libc getrandom() call (system-wide seeded PRNG)
>>
>> your suggested api does nothing for the majority of trivial randomness use cases
>
> I disagree.
> I proposed major step forward for our ecosystem: you can just go and get 49 random bytes buffer. No seeding, no new calls to Random() (or genRnd?), etc. Just get a random sequence.

Insecure randomness can just grab unixtime and poke it once. Your adding allot of complexity that I would manually untangle to find "better" 64 bits of data

> For repeating sequences, I also proposed a solution.

You proposed one new api (I get to learn, fun) that solves 1 kind of determistic replay, off the top of my head I can think of 3

You simply ignored my fuzzing example, to replay failed fuzzing unit tests you would need to be able to replay the sequence *from separate compiles and execution*. No Im not storing that manually, I need 5 lines of code ported from c ("unsafe" randomness is trivial everyone) and a someplace where a 64 bit int exists. The fuzzing lib then conditionally sets the seed or reports it before use.

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. 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.

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.

On Tuesday, 16 September 2025 at 12:08:38 UTC, Richard (Rikki) Andrew Cattermole wrote:
> On 17/09/2025 12:04 AM, Denis Feklushkin wrote:
>> Perhaps this is suitable for Phobos 3?
>
> Not for V2.

...But why? My proposal does not involve changing to the current API.

But it will be possible to declare it obsolete later, gradually