range.save

[Joseph Rushton Wakeling via Digitalmars-d]

On Friday, 27 November 2015 at 11:31:14 UTC, Jonathan M Davis 
wrote:
> Another piece of this puzzle to consider is that unless a range 
> is a value type (or at least acts like a value type as long as 
> you don't mutate its elements) or has save called on it, then 
> it fundamentally doesn't work with lazy ranges. So, at minimum, 
> we need to consider making it so that lazy ranges require 
> forward ranges (and then, assuming that we continue to have 
> save, the lazy ranges need to always call save on the range 
> that they're given).

Ah, interesting you should bring that up, as it's exactly the 
challenge of doing random number generation via a range interface 
;-)

I'm looking at this problem from a slightly different angle, 
which is that for a non-deterministic range (which is a subset of 
possible InputRanges) to be lazy, it matters that the value of 
.front is not evaluated until the first call to .front; and this 
"not yet determined" property needs to be restored after 
.popFront() is called.

Basically, you require _true_ laziness rather than the kind of 
pseudo-laziness that most Phobos ranges display, where the 
initial value of .front is determined in the constructor, and 
.popFront() determines the next value of .front "eagerly".

(N.B. "Non-deterministic" here includes pseudo-non-deterministic 
ranges, such as pseudo-RNGs.)