Given:

void foo(Range)(Range fwdR)
   if(isForwardRange!Range)
{
    auto tmp = fwdR.save;
    assert(tmp == fwdR);
}

May I assume that the assert holds for generic forward range types?

Reason: I try to write an algorithm, that is easily implementable with random access ranges, but to make it work with forward ranges I need a comparison similar to the one above.

On Sunday, 28 October 2012 at 19:42:30 UTC, Tobias Pankrath wrote:
> Given:
>
> void foo(Range)(Range fwdR)
>    if(isForwardRange!Range)
> {
>     auto tmp = fwdR.save;
>     assert(tmp == fwdR);
> }
>
> May I assume that the assert holds for generic forward range types?
>
> Reason: I try to write an algorithm, that is easily implementable with random access ranges, but to make it work with forward ranges I need a comparison similar to the one above.

No, you can't compare range contents with "==". You can use the algorithm "equal", which has a lot of logic to make it optimal when possible.

On Sunday, 28 October 2012 at 19:42:30 UTC, Tobias Pankrath wrote:
> Given:
>
> void foo(Range)(Range fwdR)
>    if(isForwardRange!Range)
> {
>     auto tmp = fwdR.save;
>     assert(tmp == fwdR);
> }
>
> May I assume that the assert holds for generic forward range types?
>
> Reason: I try to write an algorithm, that is easily implementable with random access ranges, but to make it work with forward ranges I need a comparison similar to the one above.

If you meant comparing the actual range objects using "r == r.save", that doesn't hold either: If a is a "reference semantic range", such as a class, then the saved range will be different from the old range.

Note that in both cases, this has nothing to do with RA vs Frwd.

I don't want to compare the contents of the range, but I'm
iterating a range and at some point I want to know if I have been
there before. Using RA I can just use indices.

>
> If you meant comparing the actual range objects using "r == r.save", that doesn't hold either: If a is a "reference semantic range", such as a class, then the saved range will be different from the old range.
>
> Note that in both cases, this has nothing to do with RA vs Frwd.

The classes could overload opEquals to return the correct thing.
(Note: Both of my ranges have the same type). But it'd guess they
are not required to.