getNext

[David Piepgrass]

On Monday, 9 July 2012 at 07:53:41 UTC, David Piepgrass wrote:
> I don't know if this proposal went anywhere since 2010, but it 
> occurs to me that there is a hidden danger here. alloca will 
> allocate a sequence of separate temporaries. If the collection 
> is large, the stack will overflow, and the client might not 
> have a clue what happened.

Amazing. My post unleashed four pages of comments and not one of 
them responded to my post :O

I think Mehrdad is right that an in/out range should have its own 
name to distinguish it from an input range, but that doesn't 
necessarily mean that the same interface can't be used for both.

I imagine a couple of advantages of:

>     T tmp;
>     for(T* front = r.getNext(ref tmp))
>         // do something with front

instead of:

>     for(; !r.empty; r.popFront())
>         // do something with r.front

- If the range uses late-binding, getNext() is faster because 
you're only calling one function instead of 3. When I program in 
C#, I am quite irritated enough that IEnumerator requires 2 
interface calls to get each item. Late binding, of course, is 
necessary across DLL boundaries and can help avoid code bloat.
- If an input-only range has to unpack its elements (e.g. bit 
array => bool, or anything compressed), the range doesn't need to 
unpack repeatedly every time 'front' is accessed, nor does it 
need to reserve memory inside itself for a scratch area (you 
don't want scratch areas in every range if your app keeps track 
of thousands of ranges; plus, ranges tend to get passed by value, 
right?).

That said, it may be unreasonable for the compiler to support the 
necessary escape analysis (impossible in case you're importing 
.di files)... and maybe the existing empty/popFront/front is too 
well established to reconsider? (I am not familiar with the 
status quo).