getNext

[monarch_dodra]

On Tuesday, 13 July 2010 at 03:48:08 UTC, 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.

This feels quite similar to "consumeFront"? As a matter of fact, 
isn't it just exchanging:

"Check Not Empty" then "consumeFront"
for
"getNext" then "checkNotNull"

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

My big worry here is that when the range does _not_ want to 
provide a pointer to its internals, the caller has no way of 
knowing it. Modifying the pointed object may or may not modify 
the range.

For example, "std.algorithm.map" on an Array!bool simply can't 
work with getNext. Since the implementer has no idea what he is 
operating on, the conclusion is that he simply can't use getNext 
when mutation is possible.