protocol for using InputRanges

["Luís]

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.

Some thoughts:

- A while ago I realized I did not know how some of those 
underspecified details should be implemented (I think my initial 
doubt was if the range was expected/required to enforce(!empty)). 
Assuming it was just my ignorance (and incomplete or hard to find 
documentation), I asked in the IRC channel and, IIRC, the answer 
I got there was that ranges are an abstract concept, so such 
minutia were supposed to be implementation details. From this 
forum thread and that IRC feedback, it seems that, indeed, people 
have been operating under an illusion of a shared universal 
assumption. I'm very happy to see this addressed.

- (Lots of text deleted because I was no longer sure about it ...)

- Is it allowed for an InputRange to become empty and then not 
empty again? For a finite RandomAccessRange to increase in 
length? E.g.:

     // Example 1: (with "outside" control flow)
     if(someQueue.empty)
         addStuffToQueue();
     assert(!someQueue.empty);

     // Example 2: (with only range-related control flow)
     if(!someQueue.empty)
     {
         auto n = someQueue.length;
         someQueue.popFront();
         assert(someQueue.length == n-1); // can this fail?
     }

- Is it allowed to not call front? E.g.:

     void dropAll(Range)(Range range)
     {
         while(!empty)
              range.popFront();
     }