impl ops::Try for Ordering

[calebsander]

Implements Try for Ordering, mirroring the behavior of Ordering::then(). (Applying ? to Less or Greater causes it to be returned immediately, while Equal? results in ().) This is useful for implementing lexicographic orderings, where comparisons are chained until the first one that returns non-Equal. See the examples below.

I've currently gated this behind the try_trait feature, but maybe a separate feature should be used instead? I was surprised that the test passed without #![feature(try_trait)]; is this expected behavior?

Example 1: comparing structs as #[derive(Ord)] would do

struct Test(bool, u8, &'static str);

impl Ord for Test {
    fn cmp(&self, other: &Self) -> std::cmp::Ordering {
        self.0.cmp(&other.0)?;
        self.1.cmp(&other.1)?;
        self.2.cmp(&other.2)
    }
}

Example 2: comparing iterators as Iterator::cmp() would do

fn cmp<A, I1, I2>(mut iter1: I1, mut iter2: I2) -> std::cmp::Ordering
where
    A: Ord,
    I1: Iterator<Item = A>,
    I2: Iterator<Item = A>,
{
    loop {
        match (iter1.next(), iter2.next()) {
            // If both iterators have an item available, compare them
            // and return the result if it is not `Equal`
            (Some(x), Some(y)) => x.cmp(&y)?,
            // If some iterator has finished, compare their `Option<A>` values
            // (`None < Some(_)`, so this matches the behavior of `Iterator::cmp()`)
            (x, y) => return x.cmp(&y),
        }
    }
}

[rust-highfive]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @joshtriplett (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

[scottmcm]

I was surprised that the test passed without #![feature(try_trait)]; is this expected behavior?

All trait impls are insta-stable, regardless of what attribute is put on them, sadly.

If this were able to go in unstable I'd be all for it, but the type Error = Self; here makes me think that we might not want this on stable until we're certain that the current form of the Try trait is the right one -- and right now we're pretty sure it's not, though we're also not sure how much we're stuck with it.

[calebsander]

I agree it's awkward to use Ordering as the error type when Equal will never be returned as an error. I added a new UnequalOrdering type to use as the return value instead. (I just noticed your comment on the tracking issue proposing the same implementation.)

It's unfortunate that implementations ignore stability attributes, especially since the ? operator doesn't require the Try trait to be imported. (Have there been any attempts to address this?) However, I can't think of any other Try implementation for Ordering (aside from the particulars of the Error type) that would make sense for lexicographic comparisons. The implementation seems quite useful, so I think it merits stabilization after a thorough review, if there is no way to land it unstably.

r? @scottmcm

[scottmcm]

Sorry, I should have clarified better -- we found out with impl Try for Option that the error type leaks out even though we didn't want it to. That means that if this goes in, we're somewhat stuck with being able to use ordering? in a method that returns Result, which is probably somewhat undesirable.

So my personal inclination is that -- while I think this is a good impl to have conceptually and implements the semantics I would expect -- it shouldn't happen until either:

• it's decided that it's fine to allow mixing of types like this, or
• the ? desugaring is changed so that such mixing doesn't compile.

But we'll see what T-libs has to say about things.

[Dylan-DPC-zz]

marked it as s-waiting-on-team because this is awaiting feedback by @rust-lang/libs . The discussion can be found here

[pickfire]

Doesn't seemed straightforward that not equal Ordering should propagate as error, if I were to choose I would rather add Try to bool false.

[calebsander]

Doesn't seemed straightforward that not equal Ordering should propagate as error, if I were to choose I would rather add Try to bool false.

I agree it's not obvious from the Ordering type that Less and Greater should be its "errors". My main rationale for this behavior is that its usage is quite natural in comparison functions. I think it makes more sense when viewing a Try type as Continue vs. Break rather than Ok vs. Error. Since you can't tell that two values are equal until you have checked all their pieces for equality, a comparison "continues" on Equal and "breaks" on non-Equal values.
impl Try for Ordering invites some analogies to impl Try for bool:

• Short-circuiting on Less or Greater is already implemented in Ordering::then_with(), just as short-circuiting on false is already implemented (unstably) in bool::then().
• Ord could be implemented succinctly using ? on Ordering, just like PartialEq could be implemented succinctly using ? on bool:

struct Test(bool, u8, &'static str);

impl Ord for Test {
    fn cmp(&self, other: &Self) -> std::cmp::Ordering {
        self.0.cmp(&other.0)?;
        self.1.cmp(&other.1)?;
        self.2.cmp(&other.2)
    }
}

impl PartialEq for Test {
    fn eq(&self, other: &Self) -> bool {
        self.0.eq(&other.0)?;
        self.1.eq(&other.1)?;
        self.2.eq(&other.2)
    }
}

I'm not opposed to adding impl Try for bool too, but I would argue that short-circuiting on false is even less straightforward than on Less and Greater. A bool is a fundamental bit of information, so false doesn't necessarily represent failure. (For example, slice::is_empty() returns true on an empty slice, which is often an "error" case. I could see use cases for short-circuiting on true instead, i.e. ? could implement || instead of &&.) However, Ordering is explicitly meant to represent the result of a comparison, and this is the canonical way to chain comparisons.

[m-ou-se]

We discussed this in the libs team meeting, and agreed that—at least right now—this usage of the ? operator is too different from the ones we already have (e.g. Option and Result). Right now, ? is always used to unwrap a container while early-returning the error case. Whether ? should be used for types that do not fit this pattern is a much bigger question, which should probably be discussed (also by the lang team) as part of the whole try_trait feature. (#42327)

[BurntSushi]

I wasn't at the libs meeting, but I'd like to echo my strong agreement with that position. I feel very uneasy about adding Try impls for things like bool and Ordering. I think it blows my strangeness budget personally, even if it would make some code more natural to write. For adding these impls, I personally would want to actually see the code the benefits from this and get a general idea for how common it comes up. If it's uncommon, then it seems like a "weird" use of the Try trait that anyone new to that code is going to stumble over and have to go look up and learn. At that point, I'd suggest just using a macro with a more conspicuous name.

[pickfire]

Last time I used to be thinking that Try is good for bool but I find it weird to have Try for Ordering, but thinking of what @BurntSushi mentioned feels true.

[ghost]

Suggested change

	// but uses the Try operator on Ordering values
	// but uses the `?` operator on Ordering values

For clarity

[ghost]

Suggested change

	// Implement Iterator::cmp() using the Try operator
	// Implement Iterator::cmp() using the `?` operator

For clarity.

[scottmcm]

Thanks for the PR, @calebsander!

Given this libs team feedback I'm going to close this PR. It sounds like it might be worth keeping in mind in other try-related conversations, but that we probably need more experience with other things before we can consider it.

[scottmcm]

For anyone following along, I've posted an RFC that would resolve my this would allow ordering? in a -> Result method concern: rust-lang/rfcs#3058

Note, however, that said RFC takes no position on whether implementations like this on on Ordering should happen. Anyone interested in reopening this in future would still need to resolve the unease mentioned above.