getNext

[Mehrdad]

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.

What we really need is to define a new kind of range -- perhaps 
an "input/output range", if I had to name it: it's forward-only, 
but it can be mutated and replaced. It'd be a superset of both 
input and output ranges, and also a subset of bidirectional 
ranges.

But without formally defining a new kind of range, we're just 
saying "I want an input range that's also kinda-sorta an output 
range. Ooh, I also want to be able to mutate it! But I can't seek 
backwards, so it's not bidi. Hmm, not sure what to call it, so 
I'll just put constraints for everything I need and hope it makes 
sense."

It (obviously) /works/, but it doesn't make sense semantically, 
the way it's defined right now.