Dconf 2015 talks...

[Era Scarecrow via Digitalmars-d]

On Monday, 25 January 2016 at 21:20:09 UTC, Joseph Rushton 
Wakeling wrote:
> I thought that too, for a long time, but I came to the 
> conclusion it's not the case.
>
> <snip>
>
> That's fine if you're dealing with something whose behaviour is 
> meant to be deterministic, but if you call this with a 
> pseudo-random sequence, than every time you call it, you will 
> get the same result.  It won't matter if what you pass is a  
> reference-type -- the .save (which is correct behaviour for 
> handling a forward range) means you're just repeatedly using a 
> copy of the random sequence.
>
> <snip>
>
> Right -- non-PRNGs must be input ranges by design.  I came to 
> the conclusion that pseudo-RNGs need to be input ranges, but 
> that implement an alternative to .save: a .dup method whose 
> promise is, "You can duplicate the state and hence behaviour of 
> this range, but you can't make any assumptions that this is a 
> safe or sane thing to do."


  So in short, the RNG shouldn't be a range at all. Of course it 
could be a struct (for sanity and other reasons), but not a range.

  I wonder then, assuming we remove RNG from being a range, the a 
RNG could give out a delegate of it's current data, and that 
delegate get passed to a range-like wrapper? Or maybe the RNG 
returns a Voldemort range that referrs to the original RNG which 
isn't a range anymore... Actually that sounds promising. Aliasing 
could deal with it automatically converting/creating the range.