Ranges and random numbers -- again

[monarch_dodra]

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/oiczxzkzxketxitncghl@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/kuvhrfnrrbhzpyoirqgt@forum.dlang.org
http://forum.dlang.org/thread/mailman.259.1357667544.22503.digitalmars-d@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.