protocol for using InputRanges

[monarch_dodra]

On Thursday, 27 March 2014 at 15:45:14 UTC, Andrei Alexandrescu 
wrote:
> On 3/27/14, 8:44 AM, Steven Schveighoffer wrote:
>> On Thu, 27 Mar 2014 11:40:59 -0400, Andrei Alexandrescu
>> <SeeWebsiteForEmail at erdani.org> wrote:
>>
>>> On 3/27/14, 5:35 AM, Steven Schveighoffer wrote:
>>>> BTW, I think there has been recent talk about not focusing 
>>>> on dust when
>>>> we are laying bricks. This would have my vote as useless 
>>>> dust. This does
>>>> not solve the problem of streams-as-ranges, because streams 
>>>> don't make
>>>> good ranges. It doesn't really solve any problems as far as 
>>>> I can tell.
>>>
>>> I think byXchar are important and are not streams. -- Andrei
>>
>> What's broken about those?
>
> Speed.

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.

Furthermore, popFront() has a guaranteed "1 call" per element. 
Weareas "empty" and "front" may be called several times in a row 
for a single element.

If you want efficiency, stop being "member-wise" lazy, and put 
some eagerness in your code.

> filter comes to mind. -- Andrei

You *just* turned down a pull that did exactly that, for exactly 
the same reasons.

Have "byXChar" function like filter: construction and popFront do 
the work, and front/empty is 0(1), and const, and strongly pure 
to boot. I *know* the compiler likes that in terms of speed.