protocol for using InputRanges

[Regan Heath]

On Wed, 26 Mar 2014 16:38:57 -0000, monarch_dodra <monarchdodra at gmail.com>  
wrote:

> On Wednesday, 26 March 2014 at 15:37:38 UTC, Steven Schveighoffer wrote:
>> 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.
>>
>> -Steve
>
> Not only that, but it's also a performance criteria: If you are  
> iterating on two ranges at once (think "copy"), then you *know* "range2"  
> is longer than "range1", even if you don't know its length.

What guarantees range2 is longer than range1?  The isArray case checks  
explicitly, but the generic one doesn't.  Is it a property of being an  
output range that it will expand as required, or..

> Why pay for "range2.empty", when you know it'll always be false? There  
> is a noticeable performance difference if you *don't* check.

But aren't you instead paying for 2 checks in front and 2 in popFront, so  
4 checks vs 1?  Or is the argument that these 4 checks cannot be removed  
even if we mandate r.empty is called before r.front/popFront.

R

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