getNext

[Jonathan M Davis]

On Monday, July 09, 2012 21:19:46 Mehrdad wrote:
> On Monday, 9 July 2012 at 18:33:26 UTC, jerro wrote:
> > On Monday, 9 July 2012 at 16:22:05 UTC, Mehrdad wrote:
> >> Perhaps if you could show an actual example of what you expect
> >> to be able to do, that would make things clearer?
> > 
> > It is useful to be able to write an algorithm that both reads
> > and writes range elements. There are plenty of use cases for
> > that, but if you really need an example, here's a simple one:
> > 
> > void transform(alias f, R)(R r)
> > 
> >     if(isInputRange!R && hasAssignableElements!R)
> > 
> > {
> > 
> >     for(; !r.empty; r.popFront())
> >     
> >         r.front = unaryFun!f(r.front);
> > 
> > }
> 
> Wow, thanks a bunch. That makes it a LOT more clearer than
> explanations. :)
> 
> The trouble here is that the use case is valid, but the design of
> ranges doesn't really match it.
> 
> Why? Because the way it currently stands, isInputRange &&
> hasAssignableElements is basically isOutputRange (with also input
> capability), which doesn't make any sense.

Except that how output ranges are written to and an input range with 
assignable elements are fundamentally different. Output ranges use put, which 
_might_ write to each individual element, or it may just append to the output 
range (it all depends on the implementation of put). You're essentially 
generating a range when you use an output range. But with an input range with 
assignable elements, you're specifically setting each element in an existing 
range rather than generating a new one. You can think of an output range like 
an output stream, whereas an input range with assignable elements is like an 
array where you're assigning values to each of its elements.

- Jonathan M Davis