protocol for using InputRanges

[Walter Bright]

On 3/26/2014 7:19 PM, Steven Schveighoffer wrote:
> if(!r.empty)
> {
>     auto r2 = map!(x => x * 2)(r);
>     do
>     {
>        auto x = r2.front;
>        ...
>     } while(!r2.empty);
> }
>
> Should we be required to re-verify that r2 is not empty before using it? It
> clearly is not, and would be an artificial requirement (one that map likely
> would not enforce!).
>
> This sounds so much like a convention that simply won't be followed, and the
> result will be perfectly valid code.

The idea is that there are three functions: empty, front, and popFront. The 
functionality of the range will be distributed between these 3 functions. 
Different things being ranged over will naturally split their operations into 
the 3 functions in different ways.

If the 3 functions can be called in any order, then extra logic has to be added 
to them to signal to each other. This slows things down.

To write generic code calling ranges, it's necessary to stop assuming what is 
happening under the hood of empty, front, and popFront, and stick to the protocol.