Ranges and random numbers -- again

[Joseph Rushton Wakeling]

On 06/18/2013 05:00 AM, Andrei Alexandrescu wrote:
> On 6/17/13 6:29 PM, Joseph Rushton Wakeling wrote:
>> On 06/17/2013 11:18 PM, Joseph Rushton Wakeling wrote:
>>>> 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".
>>>
>>> Completely agree, and I don't think this is in contradiction with what I've
>>> proposed.  My proposed "rule" might be better stated to clarify this.
>>
>> Perhaps this would be a better statement:
>>
>>      ************************************************************************
>>      * Iterating fully over a given random range should produce a different *
>>      * sequence for each such complete iteration.                           *
>>      ************************************************************************
>>
>> So, if you do,
>>
>>      SomeRandomRange r;
>>      x = r.front;
>>      y = r.front;
>>      assert(x == y);  // Passes!!
>>
>> But
>>
>>      SomeRandomRange r;
>>      arr1 = array(r);
>>      arr2 = array(r);
>>      assert(x != y);  // the two arrays are filled with different sequences.
> 
> Once you consume an input range, there's no way to consume it again. It's done.

Let me be certain I understand what you're saying.  Is it that something like this:

    SomeInputRange r;
    arr1 = array(r);
    arr2 = array(r);

... is not legit?  Or are you saying that the properties I've described are
simply the properties of input ranges?

If the latter, then note that what I'm proposing is something stronger than
just, "Random ranges should be input ranges."  Once again I should rephrase:
"Iterating fully over a given random range should produce a different and
statistically independent sequence for each such complete iteration."

I don't come to that conclusion because I _want_ random ranges to be
un-.save-able, but because I think without that design choice, there will simply
be too many ways to unknowingly generate unwanted correlations in
random-number-using programs.

I'll follow up on that point later today.