[ Stephan Tolksdorf adds pre-Bellevue: ]

Change row 3 of table 105 "Random number engine requirements" in [rand.req.eng]/3

Creates an engine with initial state determined by static_cast<X::result_type>(s)

Similarly, change [rand.req.adapt]/3 e)

When X::X is invoked with an X::result_type value s of arithmetic type (3.9.1), ...

Proposed resolution:

See N2424 for further discussion.

[ Bellevue: ]

Propose close NAD for the reasons given in N2424.

[ Stephan Tolksdorf adds pre-Bellevue: ]

In reply to the discussion in N2424 regarding this issue:

The descriptions of all engines and engine adaptors given in sections [rand.eng] and [rand.adapt] already specify the concrete types of the integer arguments for seeding. Hence, relaxing the general requirement in [rand.req.eng] would not affect portability and reproducibility of the standard library. Furthermore, it is not clear to me what exactly the guarantee "with initial state determined by static_cast<X::result_type>(s)" is useful for. On the other hand, relaxing the requirement would allow developers to implement other random number engines that do not have to cast all arithmetic seed arguments to their result_types.

The 3rd table row in [rand.req.eng]/3 requires random number engines to accept any arithmetic type as a seed, which is then casted to the engine's result_type and subsequently used for seeding the state of the engine. The requirement stated as "Creates an engine with initial state determined by static_cast<X::result_type>(s)" forces random number engines to either use a seeding method that completely depends on the result_type (see the discussion of seeding for the mersenne_twister_engine in point T2 above) or at least to throw away "bits of randomness" in the seed value if the result_type is smaller than the seed type. This seems to be inappropriate for many modern random number generators, in particular F2-linear or cryptographic ones, which operate on an internal bit array that in principle is independent of the type of numbers returned.

Possible resolution: I propose to change the wording to a version similar to "Creates an engine with initial state determined by static_cast<UintType>(s), where UintType is an implementation specific unsigned integer type."

Additionally, the definition of s in [rand.req.eng]/1 c) could be restricted to unsigned integer types.

Similarly, the type of the seed in [rand.req.adapt]/3 e) could be left unspecified.

See N2424 for further discussion.