getNext

[Jonathan M Davis]

On Monday 12 July 2010 20:48:05 Andrei Alexandrescu 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?
> 
> 
> Andrei

What happens to empty, front, and popFront then? Is this a case where something 
must define either empty, front, and popFront or getNext to be an input range? Or 
is this something else? Personally, I find empty, front, and popFront quite 
useful and simple for anything that I've done, and I'd find getNext to be a lot 
more verbose. getNext may be great if you're using empty, front, and popFront 
pretty much simultaneously, but if you don't want to use all of them for 
whatever you're doing, then getNext is overkill.

So, essentially, I suppose the issue is that I don't see what you intend to do 
to front, popFront, and empty if you add getNext into the mix. I do not want to 
see front, popFront, or empty go away. Having getNext as an additional function 
to make it easier to iterate over a range and do something with each element as 
you iterate wouldn't hurt my feelings any, but I definitely don't want to lose 
popFront, empty, or front.

As for simplification, it strikes me as more complicated in every case except 
where you are iterating over a range and processing each element as you iterate. 
Granted, that's a common use case, but there are plenty of other cases, where if 
you were forced to use getNext instead of having popFront, empty, and front, 
that would be a major problem.

- Jonathan M Davis