Proposed resolution:

See N2424 for the proposed resolution.

[ Bellevue: ]

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

The proper way to seed random number engines seems to be the most frequently discussed issue of the [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 [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 [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 [rand.eng] appropriately (the actual implementation could be done using the SFINAE technique).