On Fri, Nov 19, 2021 at 2:00 PM Jason McKesson <jmckesson_at_[hidden]> wrote:

> On Fri, Nov 19, 2021 at 1:20 PM Arthur O'Dwyer <arthur.j.odwyer_at_[hidden]>
> wrote:
> > On Fri, Nov 19, 2021 at 1:09 PM Jason McKesson via Std-Proposals <
> std-proposals_at_[hidden]> wrote:
> >
> > The operation of "specifying a number of bits to take from
> random_device, and then 'key-stretching' those into a larger seed value
> suitable for MT19937," sounds like a perfect job for... a PRNG. ;)
> >
> > // Consume a lot of randomness from the OS to seed mt19937
> > auto g = nonstd::mt19937(std::random_device{});
> >
> > // Consume only 256 bits of randomness from the OS to seed xoshiro256ss;
> > // then consume a lot of pseudo-randomness from xoshiro256ss to seed
> mt19937
> > auto g = nonstd::mt19937(nonstd::xoshiro256ss(std::random_device{}));
>
> `seed_seq` does something more or less like this already. Obviously it
> uses a different algorithm, so it might be useful to have a
> `seed_rng<rng_engine>` type where `rng_engine` is any engine, and the
> engine will be seeded from `random_device`.
>

[Assuming std-proposals was dropped accidentally; if not, my apologies.]

The crappy thing about `std::seed_seq` is that it's heap-allocating — it's
basically a thin wrapper around a `std::vector<uint32_t>`. (This is what
made it so painful to reproduce Melissa O'Neill's results at the beginning
of this thread: you not only have to loop 2^32 times with a gigantic array
initialization in the inner loop, but you have to do it with a
*heap-allocation* in the inner loop, because seed_seq.)

What we really want is not a "heap-allocated seed *sequence*" but rather a
"seed sequence *generator*," where you can ask it to generate any arbitrary
quantity of pseudo-random bits and it'll just... oh wait, that's a random
number engine, and *we already have those*. ;)
`std::seed_seq` has never had any practical reason to exist.

–Arthur