protocol for using InputRanges

[Regan Heath]

On Wed, 26 Mar 2014 15:37:38 -0000, Steven Schveighoffer  
<schveiguy at yahoo.com> 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.

Sure, it's not required for some algorithms in some situations.

> 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.

Sure, as above, makes perfect sense.

It seemed from this thread that there was some confusion about how ranges  
should be written and used, and I thought it might help if the  
requirements were more fixed, that's all.

If r.empty was mandatory then every range implementer would have a place  
to lazily initialise, r.front would be simpler, r.popFront too.  Basically  
it would lower the bar for "good" range implementations.

We might just need better documentation tho.

R

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/