more methods for Iterators.Reverse?

[Hamiltonian-Action]

I am not perfectly certain whether this would be considered a documentation issue, an implementation issue, or a bit of both. However, to my understanding, there is quite a bit of vagueness around what is automatically supported via the Iterators.reverse functionality. For instance, the length method seems to be inherited from the underlying iterator but :(==), copy, and eltype are not.

Whilst this is indeed a problem for those wishing to develop their own customised implementations, this also extends to the level of the standard library structures themselves as they too lack full coverage. Again, as an example, both Array and Dict fortunately have matching eltype with their reversed wrappers but the latter still lack methods for copying and checking equivalence.

Edit: I stand corrected, I merely misread the interface specification as eltype(::T) rather than eltype(::Type{T}).

[stevengj]

eltype is already inherited from the parent iterator of a Reverse iterator. See https://github.com/JuliaLang/julia/blob/eda80bcdf7f8af6334d9f4c15006df23c78d0d0d/base/iterators.jl#L125C1-L132C65

We could certainly add a method for copy. The == function defaults to ===, but again we could add a specialized method. In practice I doubt either of these functions is used very often for Reverse iterators … they are mostly just used for iteration and for passing to functions like filter or map that expect iterators, but which are unlikely to need to copy the iterator.

[tejaswiverma121-byte]

Would it be appropriate to add copy and == methods for Reverse
iterators? I'd be happy to implement these if maintainers think it's
worth adding.

[stevengj]

The other iterator types generally don't have copy implementations either, e.g. itr = Iterators.filter(!=(0), [1,0,2,0,3,0]) throws a MethodError on copy. It's not clear to me why Reverse should be different?

Do you have a use-case in mind where you need copy or a specialized == on Reverse iterators?

[tejaswiverma121-byte]

That's a fair point! I don't have a specific use-case in mind.
I'll leave this to the maintainers to decide. Thanks for the clarification!

[Hamiltonian-Action]

It is not particularly a major concern, just a curiosity that popped up during unit testing which consisted of several rounds wherein a random direction was chosen for each journey through the gauntlet. This then indeed produced some unanticipated errors as neither A == B, all(x -> first(x) == last(x), zip(A, B)), nor their conjunction indeed imply that Iterators.reverse(A) == Iterators.reverse(B), though the latter does imply (assuming proper compliance) that all(x -> first(x) == last(x), zip(Iterators.reverse.((A, B))...)). To be clear, the objects in question are not merely iterators but they do strive to also be compatible with the iteration interface.
The key point I would be concerned about is just improving the documentation regarding what is available by default versus what ought to be explicitly implemented, especially since reversed iteration is stated to be an opt-in feature that requires specific methods to be developed in order to support it.

[stevengj]

But none of this is specific to Reverse — in general, we don't have an == operation for arbitrary iterators. Your only option is to check something like length(A) == length(B) && all(splat(==), zip(A, B)) or maybe length(A) == length(B) && mapreduce(==, &, A, B).

The only methods implemented for Reverse, as for other iterators, are ones that are defined by the iteration protocol, which is documented here: https://docs.julialang.org/en/v1/manual/interfaces/#man-interface-iteration