Ordering::and_then

[digama0]

From rust-lang/rust#34774:

This seems like an obvious and missing function from std::cmp::Ordering:

impl Ordering {
    pub fn then(self, other: Ordering) -> Ordering {
        match self {
            Ordering::Equal => other,
            o => o,
        }
    }

    pub fn and_then<F: FnOnce() -> Ordering>(self, other: F) -> Ordering {
        match self {
            Ordering::Equal => other(),
            o => o,
        }
    }
}

This is useful for creating comparators which do lexicographic order. The second variant allows for skipping the order calculation if it is not necessary.

To explain the name then / and_then: Java has a similar function for comparators, called thenComparing. The idea is that you can read a comparison function like

self.name.cmp(other.name).then(self.address.cmp(other.address))

as "compare by name, then by address". The then / and_then difference with a closure is inspired by Rust's function names for Option like or (by value) / or_else (by closure).

[ExpHP]

Bikeshed: To me or_else actually feels more to me like the proper name for this, as it short circuits once it reaches some sort of non-neutral value. (Equal playing a role similar to None or false)

[digama0]

@ExpHP To add to the similarity, this is also the behavior of javascript's || operator - it returns the first truthy value, which would act like this function if the values are represented as -1, 0, 1. I am not attached to any particular name.

[rednum]

Is there any update on this? I'd also like to have this feature, can I contribute somehow?

@digama0 This would also be similar to Haskell's monoid instance for Data.Ord.Ordering.

[digama0]

@rednum I like that, that's a clever use of monads. (I assume you meant monad not monoid which is a very different algebraic structure.)

[sfackler]

@rednum These seem like reasonable APIs that match conventions, so it should be fine to just add them (marked unstable) and open a PR against rust-lang/rust!

[rednum]

@digama0
I've meant monoid, see:
https://hackage.haskell.org/package/base-4.9.0.0/docs/src/GHC.Base.html#line-302
so the example in original post would look something like this in Haskell:

myComparator self other = 
    (name self `compare` name other) `mappend` 
    (address self `compare` address other)

@sfackler
I also thought that something like this could be useful, thoughts?

impl Ordering {
    pub fn then_cmp(self, o1: &Ord, o2: &Ord) -> Ordering {
        match self {
            Ordering::Equal => o1.cmp(o2),
            o => o,
        }
    }

so that you could write

self.name.cmp(other.name).then_cmp(self.address, other.address)

[abonander]

@rednum That's functionally equivalent to and_then() but less flexible:

self.name.cmp(other.name).and_then(|| self.address.cmp(other.address))

[sfackler]

That could be convenient, yeah, though I'd personally lean towards just and and and_then for now to match with Option &co.

[bluss]

and seems better than or, since the latter mismatches. Compare to an expression like a == b || c <= d where the second comparison is done when a and b are not equal.

Why not just use chain as the name? The conjunctions really have to fit perfectly, otherwise I wouldn't use them.

[rednum]

I think chain is better than and/or. How about the variant that takes function? I put it for consistency with Option, but I don't think it's really necessary, and neither chain_then or chain_fn sound convincing to me.

[clarfonthey]

This function is a bit awkward to use in implementations of PartialOrd.

For example, let's take a simple tuple for Ord:

fn cmp((t11, t12): (usize, usize), (t21, t22): (usize, usize)) -> Ordering {
   t11.cmp(t21).then_with(|| t12.cmp(t22))
}

That's pretty simple, but:

fn partial_cmp((t11, t12): (f64, f64), (t21, t22): (f64, f64)) -> Option<Ordering> {
   t11.partial_cmp(t21).and_then(|c1| {
        if let Some(c2) = t12.partial_cmp(t22) {
            c1.then(c2)
        }
    })
}

Note that you can't easily do a then_with for partial_cmp. Either that or I can't figure it out.

Perhaps there should be a version of these functions that works with Option<Ordering>?