reverse iteration for `eachsplit`

[stevengj]

As commented in #39245 (comment), it would be nice to add iterate methods for Iterators.Reverse{SplitIterator} — in general, for any iterator where it is feasible to do so, we'd like to support reverse iteration, and this must be implemented in Base to avoid type piracy.

Currently, e.g. collect(Iterators.reverse(eachsplit("a.b.c", '.', limit=2))) gives a MethodError because it tries to fall back on the generic method that requires indexing.

(Would also be helpful in #43557, since it would give us an easy rsplit method that outputs a type-stable tuple.) This is distinct from an eachrsplit iterator.

Note that the case with a limit argument seems a bit tricky to implement, since it seems like you would first need to count all the delimiters in the string, an O(n) operation, in order to figure out how many delimiters to skip at the end.

[jakobnissen]

I would like to give a go implementing eachrsplit. However, I think the only way to do this in a non-allocating way is to return the elements as found from right to left, in the opposite order of rsplit. I simply can't think of any reasonable way to implement eachrsplit that iterates left-to-right, without making it strictly worse than rsplit.

CC'ing @stevengj @vtjnash - before I put in the work, would such a right-to-left iterator be a good addition to Base? See also #45385 and #46745

[stevengj]

Note that an eachrsplit iterator is distinct from an Iterators.Reverse{SplitIterator} iterator:

• Iterators.Reverse{SplitIterator} should be functionally equivalent to iterating over reverse!(collect(eachsplit(...)) … as I commented, however, it couldn't efficiently support a limit argument.
• an eachrsplit can simply search from right-to-left, and have a limit argument; it need not be equivalent to reversing the output of eachsplit.

[jakobnissen]

You're right, they behave differently when limit > 0.