protocol for using InputRanges

[monarch_dodra]

On Wednesday, 26 March 2014 at 16:55:48 UTC, Regan Heath wrote:
> On Wed, 26 Mar 2014 16:38:57 -0000, monarch_dodra
>> 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..

The interface: The target *shall* have enough room to accommodate 
origin. Failure to meet that criteria is an Error.

Output ranges may or may not auto expand as required. Arguably, 
it's a design flaw I don't want to get started on.

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

I don't know what checks you are talking about. Most ranges don't 
check anything on front or popFront. They merely assume they are 
in a state that where they can do their job. Failure to meet this 
condition prior to the call (note I didn't say "failure to check 
for"), means Error.

It's really not much different from when doing an strcpy. "++p" 
and "*p" don't check anything. The fact that ranges *can* check 
doesn't always mean they should.