julia> Reversed(Reversed([1,2,3]))
Reversed{Reversed{Array{Int64,1}}}(Reversed{Array{Int64,1}}([1, 2, 3]))

Any reason not to return the original object instead?

EDIT: actually, the current result above cannot even be iterated over, throwing MethodError: no method matching start(::Reversed{Reversed{Array{Int64,1}}}).

Also, reverse(Reversed([1,2,3])) throws a MethodError: no method matching reverse(::Reversed{Array{Int64,1}}).

Should probably add definitions like

Reversed(r::Reversed) = r.iter
reverse(r::Reversed) = copy(r.iter)

Would it be worth adding something like

getindex(r::Reversed, i::Integer) = reverseind(r.iter, Int(i))

?

@ararslan, I thought about adding getindex, but I forgot about reverseind so I didn't see how to do it generically, and for arrays we can already use views for reverse-order indexing.

However, I'm still not sold on getindex. It's not that useful in this context for strings unless we also add nextind etcetera, and in general we don't usually define getindex for iterators.

I would have like to have used lower-case for the function, analogous to enumerate, zip, etcetera, but it is too confusing given that we already have a reverse function. Reverse-order iteration seems so basic, however, that I think it is worth exporting Reversed.

Any other bikeshedding on the name?

Calling it Reversed and exporting it seems okay to me.

Note: 44e383f is a bugfix that should be backported to 0.6. So, that commit should not be squashed with the others when/if this PR is merged.

I don't think calling it reversed would be so bad, might in fact be preferable to calling it Reversed.

I disagree; I think the difference between reverse and reversed is too subtle.

Using caps does emphasize that it is a wrapper type (a “noun”) rather than a transformation of the underlying data (a “verb”).

Of course, one could similarly question why we don’t capitalize zip.

Of course, one could similarly question why we don’t capitalize zip.

In the very specific case of zip, the function returns a different type (Zip1, Zip2, or Zip) depending on the number of arguments. So it's a bit different from Reversed in that regard.

We already have filter and Iterators.filter, the latter returning a Iterators.Filter iterator. Why not have reverse and Iterators.reverse, the latter returning an Iterators.Reverse iterator? That would be more consistent than reversed returning a Reversed iterator.

Note that we actually once did have a Reverse iterator, which was removed by @JeffBezanson for Julia 0.2 because it relied on getindex (#4590). Base.Order subsequently exported Reverse (#6780).

Probably we should have a reverse(x) = collect(Reversed(x)) fallback too.

I think one generally wants a similar kind of collection when reversing, so that fallback might need some tweaking. In general, I suspect that having a general fallback for reversal is not worth it and we should just supply the methods where we know what to do and let people fill in the rest.

@StefanKarpinski, my objection is that it seems really weird and surprising for a collection to support Reversed but not reverse. (For example, Reverse supports n-dimensional arrays, but reverse does not, and neither does reverse(collect(a)).)

Imagine the user questions: "How do I reverse the order of this collection? reverse doesn't work, and neither does reverse(collect(x))" .... we answer: "Use collect(Reversed(x))" ... "Why wasn't this the default?" ... "Ummm...."

Another way of saying it: this reduces the number of methods a collection needs to implement. If reverse-order iteration is worthwhile, so you implement Reversed{T} methods, wouldn't you want reverse to work too?

@nalimilan's Iterators.reverse suggestion seems reasonable to me.

@stevengj, I'm willing to live with a few awkward questions about missing features in 1.0 rather than adding new, half-baked functionality that we then have to live with for a decade, no matter how wrong it turns out we are about how it behaves.

Okay, I removed the Base.reverse fallback, and renamed to Iterators.reverse and Iterators.Reverse.

Yeah, there have been a few issues with Circle, particularly x86-64, lately.

For comparison, the Python reversed iterator (PEP 322) only works for indexable collections. (We used to do the same thing, but removed it: #4590.) In Swift, the reversedcollection iterator only works for collections with "bidirectional indices", which is essentially equivalent to requiring getindex plus prevind and nextind. Ruby's reverse_each apparently only works on arrays (i.e. requires getindex). The only fully general lazy iterator reversal protocol I've come across in the "standard" libraries of other languages is Boost's bidirectional traversal concept and resulting reverse iterator.

Rebased to fix conflict.

Note: if/when this is merged, don't squash since the bugfix commit should be backported.

It looks like this was squashed, but wasn't this supposed to be not squashed?

It was not squashed.

Ok, sorry for the noise!