New Lagged Fib. PRNG gen and random2.d

[monarch_dodra]

On Wednesday, 28 August 2013 at 17:57:13 UTC, Joseph Rushton 
Wakeling wrote:
> 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.

I agree that classes over structs is appealing, but I still think 
that having "semi-Public payload implementations" is important. 
There are a lot of devs out there that don't use the GC, in 
particular video games. It would be nice for them to not have to 
re-write the wheel.

With that said, even with classes, we'd need an easy way to 
create the classes from the payloads.