protocol for using InputRanges

[Chris]

On Friday, 28 March 2014 at 04:58:28 UTC, Walter Bright wrote:
> On 3/27/2014 3:21 AM, Chris wrote:
>> I agree. I've been using ranges for a while now and have tried
>> different implementations based on advice given on this forum 
>> and
>> depending on each case. After reading this thread I looked at
>> some of my ranges and I have to say I still have no clue as to
>> what should and should _not_ be done (regardless of whether you
>> _can_ do it). For a while I thought that it's my lack of
>> understanding, but this thread shows that everyone has a
>> different view of ranges. Guidelines with use cases would be
>> great. I remember I mentioned this in another thread already. 
>> The
>> thing is that experimenting without proper guidelines leaves 
>> your
>> code in an inconsistent state where you have two or more ranges
>> doing technically the same thing but each with a different 
>> logic.
>
> Following the protocol empty-front-popFront always works.
>
> Where the differences come in is when people skip calling empty.

Not only there. The whole issue of front and popFront has not 
been made clear yet (unless it's my lack of understanding). What 
should and should not be done there, even if you stick to the 
basic protocol (!empty > front > popFront).

I like the concept of ranges and use them a lot, because they 
help me to create independent components. But sometimes I think 
they are just glorified for-loops in the sense that we know more 
or less what the input is, and part of the reason why we have 
this thread is that we want everything to be specialized and 
generic at the same time. E.g.

@monarch_dodra wrote:

"It's not that *you* know a particular range doesn't need "empty"
called, it's that the algorithm you are using has already
previously validated there are elements in it.

For example, the splitter algorithm will first save a copy of its
range, and then walk it, searching for the "splitting" elements.
It then realizes it has walked N elements."

But then it's no longer generic. If your range depends on another 
algorithm (that you assume or know to have checked something), 
then it's no longer generic. In many cases "generic" means an 
overhead of checks, and is anathema to performance tuning. I 
think it's the issue of generic vs. specialized / optimized that 
started this thread. And this is a tough one to sort out.