protocol for using InputRanges

[Steven Schveighoffer]

On Thu, 27 Mar 2014 11:19:15 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 3/27/14, 3:49 AM, "Marc Schütz" <schuetzm at gmx.net>" wrote:
>> I was originally going to do that, but then I took a closer look at the
>> documentation, which says ([1] in the documentation of  
>> `isInputRange()`):
>>
>> "Calling r.front is allowed only if calling r.empty has, or would have,
>> returned false."
>
> Probably we need to amend that. For efficient ranges, front() and  
> popFront() should only be guaranteed to work if either empty() or  
> length() were evaluated first, and they returned false or nonzero,  
> respectively.

This is a misleading statement. An array is probably the most efficient of  
ranges, which does not require this.

We should be more specific here. For certain types of *nonempty* ranges,  
front is only guaranteed to work if empty/length was called before front  
is called. I would not necessarily lump popFront into that requirement  
automatically, popFront may be able to cope with not having cached the  
first element without losing efficiency.

Questions to answer:

1. What types of ranges does this rule apply to?
2. What is the cost of not requiring this in terms of efficiency and ease  
of implementation.
3. Is there a better mechanism to use than misusing empty? should we  
introduce another property/call?

At the moment, the only candidates I can think of are lazy caching ranges.  
How many of those exist?

-Steve