Notices by jorendorff (jorendorff@kfogel.org)

I stan sort_by_key. It's the elegant sort_by.

Rust's type system will be finished when sort_by_key can use sort keys that include borrowed references, so you can sort on string fields without cloning them. (This would be safe, but currently the type system can't express the bound properly.)

Rust has f32/f64::total_cmp for sorting floats, but I wish it had f32/f64::sort_key returning i32/i64, or maybe just impl Ord. Then you could use a float field as a component of a tuple sort key, etc. And I could retire a dependency (ordered-float).

It's bad in Rust that BinaryHeap<T> makes you implement Ord for the type T.

It's a little bad that BTreeSet<T> has the same requirement.

Everywhere else, three kinds of sort order are supported: sort, sort_by, and sort_by_key. BinaryHeap pressures me to add an Ord impl for a type that really shouldn't have one, when what I really want is BinaryHeap::new_by_key(|task| task.priority). I can't implement Ord for tasks without affecting the meaning of ==.

stdlib needs a new heap type. I'll just go ahead and put that on my priority queue of tasks...