`sort_by` takes a comparison fn, but `min_by`/`max_by` take a "scoring" fn

[ben0x539]

This is sorta inconsistent :(

fn sort_by(self, compare: |&T, &T| -> Ordering)

fn max_by<B: Ord>(&mut self, f: |&A| -> B) -> Option<A>

Having a comparison function is kinda more useful because then you could use min_by/max_by with non-total Ord types more easily, but it's also a bit more effort in the easy case. I dunno. fwiw, ruby's sort_by takes a "scoring"-like block and haskell's sortBy takes a comparison function.

[alexcrichton]

cc @aturon

One possibility could be that foo_by takes T to U and works on U, where foo_with takes (T, T) and goes to whatever's being expected (in these cases an Ordering).

[ftxqxd]

Has there been any progress on this? I only recently noticed this inconsistency, and it looks like sort_by has been stabilised even though {min,max}_by have not (due to this issue). I like @alexcrichton’s suggestion about _by v.s. _with, but the stable sort_by does the opposite, using a comparison function even though it ends in _by.

Python 2 provides both cmp (basically, (T, T) -> Ordering) and key (T -> U) parameters to its sorted built-in, but Python 3 switched to key alone, removing the old cmp parameter. Perhaps we should follow Python’s lead and switch to key functions, although I’m not entirely sure what the motivation for them is (other than simplicity in some cases).

[mpdn]

Key functions would not work well for min/max things without a total order like floats. Ideally you would use comparison based {min,max}_by and then use a function like Haskells comparing, as @kmcallister mentioned in #17648, for when you only want to compare keys.

Unfortunately, currently Rust functions cannot return a closure, so creating a comparing-like function seems impossible right now. So if it is comparison based it ends up being unergonomic for key comparison, and if its key based it ends up being difficult or impossible to express min or max for things without a total order.

[mpdn]

Scratch that, you actually CAN make a comparing-like function:

#![feature(unboxed_closures)]
#![feature(core)]

use std::cmp::Ordering;

pub fn comparing<F,T,B>(f: F) -> Comparing<F> where
    F: Fn(&T) -> B,
    B: Ord
{
    Comparing(f)
}

pub struct Comparing<F>(F);

impl<'a,'b,F,T,B> Fn<(&'a T, &'b T)> for Comparing<F> where
    F: Fn(&T) -> B,
    B: Ord
{
    type Output = Ordering;

    extern "rust-call" fn call(&self, args: (&T, &T)) -> Ordering {
        self.0(args.0).cmp(&self.0(args.1))
    }
}

#[derive(Debug)]
struct A(u8);

fn main() {
    let mut a = [A(4), A(2), A(6), A(9)];
    a.sort_by(comparing(|x: &A| x.0));
    println!("{:?}", a);
}

I can't get it to properly infer the parameter to the closure though. This would make it a lot more ergonomic to use a comparator based min_by and max_by.

[hatahet]

FWIW, Scala also has the sortWith/sortBy distinction:

• http://www.scala-lang.org/api/current/index.html#scala.collection.immutable.List@sortWith%28lt:%28A,A%29=%3EBoolean%29:Repr
• http://www.scala-lang.org/api/current/index.html#scala.collection.immutable.List@sortBy%5BB%5D%28f:A=%3EB%29%28implicitord:scala.math.Ordering%5BB%5D%29:Repr

[pnkfelix]

1.0 beta, P-backcompat-libs, I-needs-decision.

[shepmaster]

I'm ✨ 👍 ✨ of having {sort,min,max}_{by,with}, where *_by takes a Fn(U) -> T and *_with takes a Fn(U, U) -> Ordering, more-or-less.

[kmcallister]

2×3 = 6 functions isn't too bad as combinatorial explosion goes, but it still indicates that an important abstraction is missing. For example Option's methods had the same issue before we worked out as_ref() and such.

In this case the clear alternative is Haskell's comparing, which transforms the _with forms into the _by forms. I'm not certain that the ergonomics are acceptable in Rust, but I think they probably could be.