protocol for using InputRanges

[Steven Schveighoffer]

On Wed, 26 Mar 2014 13:36:08 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> On 3/26/14, 8:37 AM, Steven Schveighoffer wrote:
>> On Wed, 26 Mar 2014 11:09:04 -0400, Regan Heath <regan at netmail.co.nz>
>> wrote:
>>
>>> On Wed, 26 Mar 2014 12:30:53 -0000, Steven Schveighoffer
>>> <schveiguy at yahoo.com> wrote:
>>>
>>>> Gah, I didn't cut out the right rules. I meant the two rules that
>>>> empty must be called before others. Those are not necessary.
>>>
>>> I see.  I was thinking we ought to make empty mandatory to give more
>>> guaranteed structure for range implementors, so lazy initialisation
>>> can be done in one place only, etc etc.
>>
>> Yes, but when you know that empty is going to return false, there isn't
>> any logical reason to call it. It is an awkward requirement.
>>
>> I had the same thinking as you, why pay for an extra check for all 3
>> calls? But there was already evidence that people were avoiding empty.
>
> I think requiring users to call empty before front on input ranges is a  
> concession we should make.

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.

-Steve