On Monday, 25 January 2016 at 21:20:09 UTC, Joseph Rushton
Wakeling wrote:
I thought that too, for a long time, but I came to the
conclusion it's not the case.
<snip>
That's fine if you're dealing with something whose behaviour is
meant to be deterministic, but if you call this with a
pseudo-random sequence, than every time you call it, you will
get the same result. It won't matter if what you pass is a
reference-type -- the .save (which is correct behaviour for
handling a forward range) means you're just repeatedly using a
copy of the random sequence.
<snip>
Right -- non-PRNGs must be input ranges by design. I came to
the conclusion that pseudo-RNGs need to be input ranges, but
that implement an alternative to .save: a .dup method whose
promise is, "You can duplicate the state and hence behaviour of
this range, but you can't make any assumptions that this is a
safe or sane thing to do."
So in short, the RNG shouldn't be a range at all. Of course it
could be a struct (for sanity and other reasons), but not a range.
I wonder then, assuming we remove RNG from being a range, the a
RNG could give out a delegate of it's current data, and that
delegate get passed to a range-like wrapper? Or maybe the RNG
returns a Voldemort range that referrs to the original RNG which
isn't a range anymore... Actually that sounds promising. Aliasing
could deal with it automatically converting/creating the range.
