[arcticbull]

Part of the problem may be they re-implemented `std::cmp::min` at the bottom of the file, I wonder if there's a more optimized version in the stdlib.

[gpm]

One of the most frustrating parts of rust (for me), is that `std::cmp::min` (and some other methods) require that their arguments are `Ord` (totally ordered), and floats are only partially order because of NaN, so you can't use std::cmp::min on floats.

[shepmaster]

That’s what https://doc.rust-lang.org/std/primitive.f32.html#method.min is for

[arcticbull]

I do believe that's quite intentional, due to the inexactness of floating-point values, it's not "right" to do that. There should be a `partial_min` function though, IMO, which has weaker guarantees.

[gpm]

It's absolutely intentional, and it's got being technically correct on its side, it's just frustrating.

[oxnrtr]

Not really. That Rust forced total order and partial order into a sub-typing relation is a completely unnecessary, self-inflicted wound.

[steveklabnik]

Many folks do consider this a mistake. Some do still think it was the right call. I'd say it's very unclear.

[Arnavion]

You can use the ordered_float crate. It has a newtype that cannot hold NaNs and thus impls Ord.

[steveklabnik]

Depending on what behavior you want, there’s a bunch of wrapper crates.

[jfkebwjsbx]

Yeah, it makes no sense to be the default. Code that expects to treat NaNs is very rare.

[arcticbull]

Safety is the whole idea behind Rust, and if you draw the line here, that's neither in line with the Rust ethos, nor particularly valuable. After all, code that "expects to handle" null was pretty rare too ;)

[jfkebwjsbx]

NaNs have nothing to do with safety (same for nulls).

It is a common misconception to conflate safety with functional expectations. A program that only calls panic() is perfectly safe.

[arcticbull]

Ah sorry, I didn't mean safety in the UB sense, I meant in the traditional, "do what I expect, don't surprise me" sense.

[jfkebwjsbx]

Safety in Rust's context is UB-free, memory errors-free, data race-free.

Safety in software engineering is more about designing systems with some degree of assurance against certain failures, but not about surprises or expectations of a programmer.

The usage you call traditional is perhaps common, but not really rooted in anything in software engineering. I'd call it an informal meaning, maybe.

PS. No need for apologies!