protocol for using InputRanges

Jonathan M Davis jmdavisProg at gmx.com
Wed Mar 26 23:48:16 PDT 2014


On Wednesday, March 26, 2014 10:36:08 Andrei Alexandrescu wrote:
> On 3/26/14, 8:37 AM, Steven Schveighoffer 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.
> > 
> > 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.
> 
> I think requiring users to call empty before front on input ranges is a
> concession we should make.

I don't know. It's not the end of the world if we require it (at least with a 
range that doesn't have length), since you're almost always going to be forced 
to call empty anyway, because ranges are generally used in generic code. 
However, it seems really off to me for there to be any real work going on in 
empty, and I'd be leery of any range which actually required empty to be 
called before calling front (though I definitely think that calling front on 
an empty range should not be considered okay and would expect that to 
generally be undefined behavior).

Regardless, if the range has length, then I'd think that quite a few of the 
algorithms which actually used length wouldn't actually need to call empty, 
making calling empty unnecessary overhead. But for the most part, I think that 
a lot of the weird cases go away when you end up with length and random-access 
ranges and the like, since that usually means that the range isn't generative 
but likely has an array underneath (though map certainly has its quirks thanks 
to the fact that front could technically allocate a new object on every call, 
and it can be random-access).

- Jonathan M Davis


More information about the Digitalmars-d mailing list