This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of NAD status.

### 731. proposal for a customizable `seed_seq`

Section: 28.5.8.1 [rand.util.seedseq] Status: NAD Submitter: Stephan Tolksdorf Opened: 2007-09-21 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [rand.util.seedseq].

View all issues with NAD status.

Discussion:

The proper way to seed random number engines seems to be the most frequently discussed issue of the 28.5 [rand] proposal. While the new `seed_seq` approach is already rather general and probably sufficient for most situations, it is unlikely to be optimal in every case (one problem was pointed out in point T5 above). In some situations it might, for instance, be better to seed the state with a cryptographic generator.

In my opinion this is a pretty strong argument for extending the standard with a simple facility to customize the seeding procedure. This could, for example, be done with the following minimal changes:

Possible resolution:

1. Turn the interface specification of 28.5.8.1 [rand.util.seedseq]/2 into a "SeedSeq" requirement, where the exact behaviour of the constructors and the randomize method are left unspecified and where the const qualification for randomize is removed. Classes implementing this interface are additionally required to specialize the traits class in c).
2. Provide the class `seed_seq` as a default implementation of the SeedSeq interface.

3. Supplement the `seed_seq` with a traits class

   >     template <typename T>
   >     struct is_seed_seq { static const bool value = false; }

   and the specialization

   >     template <>
   >     struct is_seed_seq<seed_seq> { static const bool value = true; }

   which users can supplement with further specializations.

4. Change 28.5.3.4 [rand.req.eng]/1 d) to "q is an lvalue of a type that fulfils the SeedSeq requirements", and modify the constructors and seed methods in 28.5.4 [rand.eng] appropriately (the actual implementation could be done using the SFINAE technique).

[ Bellevue: ]

> See N2424. Close NAD but note that "conceptizing" the library may cause this problem to be solved by that route.

Proposed resolution:

See N2424 for the proposed resolution.