std.random suggestions

[monkyyy]

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.