RepeatCall shouldn't implement DoubleEndedIterator about itertools HOT 8 CLOSED

I guess you're right about that, most implementations do not make sense as double ended. You can of course run into this problem in other places, like in a regular .iter().map() too. I'm not sure what the final decision will be. After all, .map() is double ended.

from itertools.

That's... odd. I've submitted a bug to discuss it (rust-lang/rust#30632). It kind of makes sense because map (and filter) are generally pure functions but this behavior should, at least, be noted.

However, this case is pretty clear; RepeatCall always produces an infinite sequence and infinite sequences only have one end.

from itertools.

I disagree actually, infinite sequences can have two ends (For example .cycle()). Maybe cycle is a bad argument, since I wrote it 😄

from itertools.

Oh no, cycle is not double ended! My evil plans,... Ok I guess I managed to scare you there by mistake.

from itertools.

On the whole, sideeffectful iterators can always cause trouble like this. I'm leaning towards wontfixing this bug for this reason, it has use cases where double endedness is useful.

from itertools.

Infinite sequences have one end.

-- ZFC

Yes, some sequences can go backwards from the starting point but that's not double ended, it's no-ended (doubly infinite).

from itertools.

I thought this issue could stay open until we make a decision (0.5 is next breaking change opportunity).

Currently I lean WONTFIX.

from itertools.

In a crazy turn of events, I'm removing the DEI implementation in 0.5

from itertools.