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.)
