On Sunday, 23 March 2014 at 00:50:34 UTC, Walter Bright wrote:
It's become clear to me that we've underspecified what an
InputRange is. The normal way to use it is:
while (!r.empty) {
auto e = r.front;
... do something with e ...
r.popFront();
}
no argument there. But there are two issues:
1. If you know the range is not empty, is it allowed to call
r.front without calling r.empty first?
If this is true, extra logic will need to be added to r.front
in many cases.
2. Can r.front be called n times in a row? I.e. is calling
front() destructive?
If true, this means that r.front will have to cache a copy in
many cases.
In many cases it makes sense to put things into front, for
example if you read a file line by line, parsing each line to
create a dictionary entry. Although it has been said that any
logic should go into popFront, because front can be called
several times. Since Ranges usually perform some kind of
filtering mechanism and return something new, it makes sense that
things go into front, or at least should be allowed to go into
front. In my experience it is a bit of a "the hen or the egg"
problem, to get something you have to call front, but the
something should only be done in popFront. Ranges are often
simpler and faster to write, when you put things into front,
because in most of my use cases front is not called many times in
a row, just once for each item. I still haven't found the golden
way(s) of writing ranges.
