Reference semantic ranges and algorithms (and std.random)

[monarch_dodra]

On Thursday, 20 September 2012 at 11:10:43 UTC, Jonathan M Davis 
wrote:
> [SNIP]
>
> - Jonathan M Davis

#1
Hey, I've been working on this (locally): I've made all the PRNGs 
reference ranges. It actually works perfectly. I took the "ensure 
initialized" route, as you suggested. I was able to take an 
approach that moved little code, so there is a clean distinction 
between the old "Payload", which was not touched (much), and the 
wrappers. The advantage is that the diff is very clean.

I was able to do this without adding or removing any 
functionality. Great!

Regarding the cost of "is initialized", I think I found a very 
good work around. I'll show it in a pull.

#2
Johannes Pfau: When asking for a generator, by default you get a 
reference prng. This is the _safe_ approach.

If somebody *really* wants to, they can always declare a 
PRNGPayload on the stack, but I advise against that as:
*Passing it by value could generate duplicate sequences
*Passing it by value (for certain PRNGs) can be prohibitively 
expansive.

But the option is there.

#3
The only thing I'm having an issue with is "save". IMO, it is 
exceptionally dangerous to have a PRNG be a ForwardRange: It 
should only be saved if you have a damn good reason to do so. You 
can still "dup" if you want (manually) (if you think that is 
smart), but I don't think it should answer true to 
"isForwardRange".

You just don't know what an algorithm will do under the hood if 
it finds out the range is saveable. In particular, save can be 
non-trivial and expensive...

I think if somebody really wants to be able to access some random 
numbers more than once, they are just as well off doing:
Type[] randomNumbers = myPRNG.take(50).array();

The advantage here is that at no point to you ever risk having 
duplicate numbers. (Take advances the reference range generator.

QUESTION:
If I (were to) deprecate "save", how would that work with the 
range traits type? If a range has "save", but it is deprecated, 
does it answer true to isForwardRange?