On Monday, 17 June 2013 at 19:32:20 UTC, Joseph Rushton Wakeling
wrote:
In the meantime -- I'm interested in feedback on the proposed
rule. :-)
Thanks and best wishes,
-- Joe
Good analysis but (sorry) I think you are on the wrong track.
One of the major problems in std.random is that the ranges use
value semantics. This means they are *saved* whenever they are
copied, as opposed to just referenced. This creates the problems
you have mentioned, and even more.
I have tried to fix it before:
http://forum.dlang.org/thread/oiczxzkzxketxitnc...@forum.dlang.org
FWI, I gave up on the project, because it was too complex for me
to handle an entire module. But there were no reasons for it to
not work.
In any case, you can *also* take a look at these 2 other
conversations, they sup up the problem pretty quickly (especially
the second):
http://forum.dlang.org/thread/kuvhrfnrrbhzpyoir...@forum.dlang.org
http://forum.dlang.org/thread/mailman.259.1357667544.22503.digitalmar...@puremagic.com
So I don't agree with your entire point:
**************************************************************************
* Reading multiple times from the start of the same random
range, should *
* produce different (and statistically independent) results
each time. *
**************************************************************************
A random range should be viewed (IMO) as nothing more than a
range that "was" (conceptually) simply filled with random
numbers. Calling front on the same range twice in a row *should*
produce the same result: No call to popFront => no change to the
range. If it did change, it'd be a blatant violation of the range
concept. It also means you can't have safe/nothrow/pure/const
"front".
Being able to *save* a random range (which your proposal would
prevent) can have useful applications too. It means you can
iterate on the same random number sequence several times, lazily,
without having to store the results in a buffer.
The problems you are trying to fix can (imo) can be better fixed
with the reference approach.
