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.
