Making sense of ranges

[Ali Çehreli]

On 03/24/2012 04:07 PM, Stewart Gordon wrote:
> On 24/03/2012 18:57, Ali Çehreli wrote:
> <snip>
>> Iterating an output range is also by popFront(). So what it says is,
>> put this element to
>> the output range and advance the range. There is a gotcha about this
>> when the output range
>> is a slice: Whatever is just put into the range is popped right away!
>> :) [2]
>
> I'm beginning to get it now: the purpose of an output range is to put
> new data into the underlying container. So once you've put something in,
> the remaining range is what's left to be populated. I had been thinking
> of outputting in terms of appending to the range, hence the confusion.
>
>>> - Why is a range that can save checkpoints called a "forward" range?
>>
>> I agree. Here is my guess: The name of the ForwardRange comes from the
>> fact that it is not
>> double-ended. It can go only in one direction.
> <snip>
>
> Bidirectional ranges are forward ranges as well.
>
> But I've just had a look at STL iterators, and it seems that the range
> category hierarchy has been lifted from that. There, a "forward"
> iterator combines the functionality of an input iterator and an output
> iterator, hence it's your basic iterator that can move forwards and do
> what it likes with the data it walks over. (It would seem that it's only
> an "output" iterator in that * returns an lvalue, which may or may not
> be actually assignable depending on the constancy of the element type.)
>
> In D ranges, OTOH, the only thing that distinguishes a forward range
> from a general input range is the presence of a save method to make a
> copy of it.

I looked for rationale on Andrei's article. There is this bit about STL 
forward iterators:

<quote>
Input and forward iterators are syntactically identical but subtly 
different semantically—copying a forward iterator saves iteration state, 
but copying an input iterator just creates a new view of the same 
iteration state.
</quote>

I guess that's why 'save' is explicit on ForwardRange.

Ali

 > Doesn't seem to have anything to do with either the
> "forward" name or the C++ origin thereof....
>
> Something else I'm finding puzzling is moveFront, moveAt and moveBack.
> Is D trying to be C++11 or something? Move semantics don't seem to me to
> be useful in a language with GC.
>
> Stewart.