protocol for using InputRanges

[Chris]

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.