protocol for using InputRanges

[Steven Schveighoffer]

On Fri, 28 Mar 2014 07:47:22 -0400, Marc Schütz <schuetzm at gmx.net> wrote:

> On Thursday, 27 March 2014 at 16:12:36 UTC, monarch_dodra wrote:

>>
>> I call shenanigans. This is the code:
>>
>>             @property bool empty()
>>             {
>>                 if (nLeft)
>>                     return false;
>>                 if (r.empty)
>>                     return true;
>>
>> If you initialized the next element in both constructor and popFront,  
>> then you'd get rid of both these checks.
>>
>
> ... but of course lose laziness.

In this case, laziness is not critical. Decoding the element is an O(1)  
operation, and when looping through, you will decode it anyway.

When processing a 20 element string, the cost of checking to see if you  
have decoded on every empty or front call may override the front-loaded  
cost of decoding the first element on construction. It's sure to add to  
the cost if you are processing all 20 elements, since you decode them all  
anyway.

On other ranges, it's more important when the first element costs a lot to  
fetch. HOWEVER, it's not critically important to delay that unless you are  
not going to process that element. For example, if you are foreach'ing  
over all the elements, the delay doesn't matter.

I'd rather the higher level code decide whether to delay or not, depending  
on the situation. Requiring a protocol change for such detailed knowledge  
seems unbalanced.

-Steve