Add `Iterator::as_rev`

[scottmcm]

Proposal

Problem statement & motivating example

.rev() is a great iterator adapter, and combines wonderfully with everything taking self.

However, for calling iterator methods that take &mut self instead, it's less good. That leads to questions about whether there should be an rfind_map (rust-itertools/itertools#949), since if you need to call it multiple times, .by_ref().rev().find_map is a pain to type and might even be less efficient.

Solution sketch

Add the following method to Iterator:

impl Iterator {
    fn as_rev(&mut self) where Self: Sized -> &mut Rev<Self>;
}

That does mean that, from an implementation perspective, Rev needs to be repr(transparent). But I think that's fine; it's already a newtype today and it has no reason to ever keep state.

Alternatives

• Do nothing. People can make the Rev once earlier, or use by_ref().rev(), which we can continue to work on optimizations for to make it work well.
• Add more things like rfind_map so people don't ask about them. But probably never things like rall or rany, which seem kinda silly to me.

Links and related work

original find_map motivation, though it doesn't discuss the possibility of a reverse version: rust-lang/rust#49098

Example where someone used .by_ref().rev() instead: https://github.com/rust-itertools/itertools/pull/950/files#diff-2d3a79a5da014fbfcea9fc628ad9019242ea09d455f4df3cffb94bb90954cdd1R1051

What happens now?

This issue contains an API change proposal (or ACP) and is part of the libs-api team feature lifecycle. Once this issue is filed, the libs-api team will review open proposals as capability becomes available. Current response times do not have a clear estimate, but may be up to several months.

Possible responses

The libs team may respond in various different ways. First, the team will consider the problem (this doesn't require any concrete solution or alternatives to have been proposed):

• We think this problem seems worth solving, and the standard library might be the right place to solve it.
• We think that this probably doesn't belong in the standard library.

Second, if there's a concrete solution:

• We think this specific solution looks roughly right, approved, you or someone else should implement this. (Further review will still happen on the subsequent implementation PR.)
• We're not sure this is the right solution, and the alternatives or other materials don't give us enough information to be sure about that. Here are some questions we have that aren't answered, or rough ideas about alternatives we'd want to see discussed.

[joshtriplett]

We discussed this in today's @rust-lang/libs-api meeting.

We considered the two arguments separately: the verbosity of .by_ref().rev(), and the possible performance difference.

For the former, we felt that .by_ref().rev() isn't so onerous as to motivate a dedicated method.

For the latter, we'd like to know more about the potential performance issue. If there's a substantial performance win that we can't get through method forwarding or specialization, and real code is hitting the slow case, we'd be open to reconsidering this.

For now, we're inclined to reject this.

[scottmcm]

Since it sounds like it came up in the meeting, I'll note that it's definitely not precedent for as_skip or as_take, because those are parameterized and thus cannot be done as ref-to-ref, even if we wanted to.

That said, I suppose one could argue they'd be precedent for as_copied, since that's possible. But that also has the "just do it beforehand, rather than on the call" argument that often applies to rev as well.

Close unless there are real-life perf implications is good by me.