protocol for using InputRanges

[Szymon Gatner]

On Sunday, 23 March 2014 at 09:34:28 UTC, Szymon Gatner wrote:
> On Sunday, 23 March 2014 at 00:50:34 UTC, Walter Bright wrote:
>>
>> 1. If you know the range is not empty, is it allowed to call 
>> r.front without calling r.empty first?
>
> IMO: yes. Logic of empty() sould be const and not have side 
> effects.
>
>>
>> If this is true, extra logic will need to be added to r.front 
>> in many cases.
>>
>> 2. Can r.front be called n times in a row? I.e. is calling 
>> front() destructive?
>>
>> If true, this means that r.front will have to cache a copy in 
>> many cases.
>
> Yes, all true. Not sure if there is something like that in 
> Phobos but if for example you had RandomValueRange, ever call 
> to front() should return the same random number until 
> popFront() is called at which point internal front variable is 
> being recalculated and cached.
>
> Since only popFront() is non-const, it is there where all the 
> magic/mutation should happen.
>
> In my code I also have CachingRange which calls front() on 
> underlying range the first time and then stores result 
> internally. I use it for ranges which generate front() on the 
> fly and I knot it is expensive. I could cache that calculation 
> directly in that underlying range but CachingRange is reusable.

I tend to think about pair of C++ iterators, which are 
generalization of pointers. So for C pointers 'first' and 'last':

*first -> front()
first != last -> empty()
++first -> popFont()

And I stick to semantics.