On Friday, 8 April 2016 at 01:14:11 UTC, Jonathan M Davis wrote:
[...]
Lazy means that it's not going to consume the entire range when
you call the function. Rather, it's going to return a range
that you can iterate over. It may or may not process the first
element before returning, depending on how it works, and
there's definitely nothing that says whether it's going to
access front multiple times or not before calling popFront. And
accessing front multiple times without calling popFront is
_normal_ whether you're dealing with a lazy range or an eager
one. All that lazy means is that you're getting a range from
the function rather than it consuming the range before
returning.
So, whatever you do with a range, in general, you have to
assume that an algorithm might access front multiple times, and
the implementation is free to change so that it accesses it
more times or fewer times, because the range API says nothing
about whether front is accessed multiple times or not. front
needs to return equal values every time that it's called before
popFront is called, but that doesn't mean that they have to be
the same objects, and it doesn't mean that there's any
restriction on how many times front is accessed before a call
to popFront.
So, I see no reason for joiner to say anything in its docs
about how many times it accesses front. It's pretty much
irrelevant to how ranges are expected to work, and it could
change. If it actually matters for what you're doing, then you
need to figure out how to rework your code so that it doesn't
matter whether front is accessed multiple times per call to
popFront or not. That's just part of working with ranges,
though I can certainly understand if you didn't realize that
previously.
That makes sense. Thanks for the clarification.
There is another problem, map, cache, and joiner don't work
when composed multiple times. I've submitted a bug,
https://issues.dlang.org/show_bug.cgi?id=15891, can you
confirm?
Well, given your example, I would strongly argue that you
should write a range that calls read in its constructor and in
popFront rather (so that calling front multiple times doesn't
matter) rather than using map. While map can theoretically be
used the way that you're trying to use it, it's really intended
for converting an element using rather than doing stuff like
I/O in it. Also, if the range that you give map is random
access (like an array would be), then opIndex could be used to
access random elements, which _really_ wouldn't work with
reading from a file. So, I think that map is just plain a bad
choice for what you're trying to do.
So what you mean is to read the front in constructor, and read
further parts in the popFront()? that way multiple access to the
front won't hurt anything. I think it might work, I'll change my
code.
So the guideline is: when accessing front is costly, don't use
map, use a customized range struct instead. right?
It's not obvious to me why your example is failing to compile -
the problem appears to be with cache specifically and has
nothing to do with joiner - and I am inclined to agree that
there's a bug there (be it in cache or in the compiler), but I
really think that using map is a bad move for what you're
trying to do anyway - especially when you consider what will
happen if opIndex is used. I'd strongly encourage you to just
write a range that does what you need instead.
OK, hope it'll get fixed. I'll try to look for it once I'm able
to understande the code in phobos.
- Jonathan M Davis
