Tracking issue for iter_order stabilization

[aturon]

The iter module has an order submodule for performing comparisons on iterators. Ideally, these would instead just be implementations of e.g. the PartialOrd trait, but that trait passes by shared reference, and iterators must be mutated to be compared.

It'd be good to explore this design space, and perhaps write an RFC, before stabilization.

cc @bluss

[bluss]

One thing of note is that the origin of this API was to help libcollections, so that the collections didn't all have to reimplement correct PartialOrd eq, le, gt, etc handling*. With time, most of the collections maybe(?) will develop their own specialized versions and make it obsolete.

As noted in #26884, these methods are inferior for equality checking since they cannot assume that the two iterators are of equal length.

*Due to PartialOrd weirdness, every collection must implement all of lt, le, gt, ge.

[sfackler]

It seems like these should really be methods on Iterator:

pub trait Iterator {
    ....
    fn eq<E, I>(self, other: I) -> bool where Self: Sized, Self::Item: Eq<E>, I: Iterator<Item = E> { ... }
    // etc
}

[sfackler]

Would like to stabilize these in the next cycle.

[SimonSapin]

fn eq<E, I>(self, other: I) -> bool where Self: Sized, Self::Item: Eq<E>, I: Iterator<Item = E> { ... }

By the way, is this the same as

fn eq<I>(self, other: I) -> bool where Self: Sized, Self::Item: Eq<I::Item>, I: Iterator { ... }

?

[sfackler]

Your version's basically how it was actually defined when implemented: https://doc.rust-lang.org/nightly/std/iter/trait.Iterator.html#method.cmp.

[alexcrichton]

This issue is now entering its cycle-long FCP for stabilization in 1.5

[nagisa]

Can’t these be implementations of PartialEq/PartialOrd for relevant iterators instead?

[SimonSapin]

These traits take &self, while we need at least &mut self to consume the iterators here.

[alexcrichton]

The libs team discussed this during triage today and the decision was to stabilize.