More tricky range semantics

[Tobias Pankrath via Digitalmars-d]

On Friday, 16 January 2015 at 17:13:33 UTC, Joseph Rushton 
Wakeling wrote:
> On Friday, 16 January 2015 at 17:09:47 UTC, Tobias Pankrath 
> wrote:
>> While the first example is indeed problematic, this one 
>> actually is not. If this does not print the same 10 numbers 
>> every time, your save method is wrong.
>> Regardless of being a reference type or not it has to clone 
>> the RNG state or it doesn't do its job.
>
> I think you've misunderstood what I was getting at, probably 
> because I didn't explain myself well.
>
> Obviously it's correct that the second function example should 
> print out the same thing 10 times.  However, what is wrong is 
> that at the end of that function, the source range -- if a 
> reference type -- should itself have been popFront'ed a 
> sufficient number of times, but it hasn't been.
>
> That's a design fault in the function implementation, which 
> doesn't take into account the desirable behaviour (for the 
> caller) if the range given to the function is a reference type.

Ah, now I understand you. Since copy-construction is undefined 
for ForwardRanges, you cannot guarantee this. Things would be 
better, if we had required that this(this) does the same as .save 
or must be @disabled.

Than it would be clear that you either had to use a reference or 
a pointer as argument to the function.