Problem with using struct ranges with @disabled this(this) with some range functions

[anonymous via Digitalmars-d-learn]

On Wednesday 02 September 2015 09:52, Uranuz wrote:

> I want to understand if we have *save* method in Forward Range
> then why or in which cases we should use plain struct copying
> instead. Should we assume that these two ways are equal or not?

No, don't assume that they're the same.

> Also as far as I understand behaviour for Input Ranges vs Forward
> Ranges would be different, because you could not store cursor on
> object like network data stream, because as soon as you read from
> it you cannot save some range that will point on previous bytes
> in network stream, because they are gone if you read them.
> 
> So for Input Range copy will always point on current state, but
> not previois state, that was saved before in another range
> pointing to the same source.

A copy of an input range may reflect the original, but it may also become 
invalid when the original is touched. Any operation on the original 
(especially popFront) may leave the copy in an invalid state, and vice 
versa.

That means, when you make a copy of an input range, you should not use the 
original anymore.

> For Forward Range we have ability to save cursor position and
> return to it later. In this case would copying via postblit would
> be equal to *save* method or would be similar as for Input Range.

Can go either way. Copying a forward range may work like a call to `save`, 
but it's not guaranteed/required to.

When you need the behavior of `save`, call `save`. Do not assume that 
copying works like `save`.

Do also not assume that a copy and the original of a range update each other 
correctly. When you pass an input range to some function and you want the 
operation to affect the original, use std.range.refRange to pass a 
reference.