New Lagged Fib. PRNG gen and random2.d

[Joseph Rushton Wakeling]

On 25/08/13 18:58, Joseph Rushton Wakeling wrote:
>    (2) Should we provide a generic payload wrapper, or require RNG creators
>        to implement everything manually?  I strongly support a generic wrapper,
>        as there is too great a risk of implementation error if we require
>        the wrapping-of-a-reference to be done manually each time.

A few issues I ran into when trying to create such a wrapper:

     * Function properties are not necessarily (easily) consistent between
       different RNGs.  For example, it makes sense that popFront() should
       be @safe pure nothrow, but in the Linear Congruential generator
       there are casts which mean that it can't be @safe.

       Now, we _could_ go with the lowest common denominator, but that's not
       a very nice state of affairs.  Is there any way for a wrapper to
       effectively inherit the properties of the functions it's wrapping?

     * @disable this() doesn't seem appropriate for all RNGs, e.g. Xorshift.
       In fact, for _all_ RNGs you probably want to have a default
       initialization.  So, in this case, classes rather than structs start
       to look appealing.