You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is due to _Enable_if_seed_seq_t being overspecified - it excludes the type itself from overload resolution, which makes sense for the constructor (since we want the copy constructor to win), but does not make sense for seed.
The Standard ([tab:rand.req.eng] rows 5-7) says that seed must accept no argument, a result_type value, or an argument that meets the seed sequence requirements. Generally speaking, URBGs don't meet the seed sequence requirements.
TR1 (I'm looking at N1836 Table 16 rows 4-6) says that seed must accept no arguments, a result_type value, or "an lvalue of a type other than [the type of the engine that seed is a member of] that defines a zero-argument function object returning values of unsigned integral type".
We looked at this during the weekly maintainer meeting and determined that @CaseyCarter is correct - the seed sequence requirements involve many member functions such as generate() that the engines don't provide.
For every URBG in the standard library, I believe the following should work:
This is due to
_Enable_if_seed_seq_t
being overspecified - it excludes the type itself from overload resolution, which makes sense for the constructor (since we want the copy constructor to win), but does not make sense for seed.(note that this works):
discovered while investigating #2693
The text was updated successfully, but these errors were encountered: