getNext

[Andrei Alexandrescu]

On 07/13/2010 07:39 AM, Steven Schveighoffer wrote:
> 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?

I need to discuss this with Walter, he mentioned that it wouldn't be 
difficult to allow certain uses of pointers in SafeD.

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

Yup, good point.


Andrei