getNext

[Steven Schveighoffer]

On Mon, 12 Jul 2010 23:48:05 -0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> I think I figured out a comfortable and all-encompassing means to define  
> a simplified interface for an input range.
>
> Currently input ranges need to define empty, front, and popFront. That  
> works but it's a bit heavy for simple input ranges. We've been  
> discussing simplified interfaces in this group but couldn't find one  
> that satisfied all use cases.
>
> Consider this:
>
> T* getNext(R, T)(ref R range, ref T item);
>
> Semantics: if the range wants to expose addresses of its elements, it  
> returns a pointer to the current element and also advances to the next  
> element. Otherwise (i.e. the range does not have or does not want to  
> expose addresses of its elements), the range fills "item" with the  
> current value, again moves on to the next value, and returns &item.
>
> In all cases, when there are no more elements in the range, getNext  
> returns null.
>
> getNext is easy to define for e.g. arrays and files. How does it sound?  
> Does it bring significant simplification?

Yes, yes, yes!

A question though -- whenever a pointer occurs, we always cringe,  
especially in safeD.  will getNext be unsafe?

BTW, I like the alloca thingy, that's really cool.

One thing I just thought of, getNext should be split into two functions,  
the one you have, and:

ElementType!R *getNext(R)(ref R range)

To avoid having to supply the item or use alloca when the range is going  
to give you back a pointer to its internals anyways (tested with a  
template constraint).

-Steve