Unconditionally bound with T: FloatCore.

[kpreid]

Previously, the std feature was non-additive; that is, it was possible for enabling the std feature to break code in another crate. Specifically, consider the following code:

fn problem<T>(inputs: &mut [OrderedFloat<T>])
where
    T: num_traits::float::FloatCore,
{
    inputs.sort();
}

This code will compile if the std feature is disabled, but then fail when it is enabled because Ord for OrderedFloat<T> requires that T: Float, rather than T: FloatCore.

In order to eliminate this compatibility hazard, instead always require FloatCore and, where necessary, also require Float.

This is a breaking change; generic code may need updated bounds.

Also, for reasons I do not entirely understand, #[derive(PartialEq)] wouldn't compile for the UniformNotNan and UniformOrdered distribution types, so I had to replace them with ones with explicit bounds. This may be a sign that something deeper is wrong, or it might be an inadequacy of the rustc trait solver...

[mbrubeck]

Thanks! I guess this will become ordered-float 4.0. I’ll wait a little while before releasing it, to figure out if there are any other breaking changes we want to bundle in at the same time.

[mbrubeck]

ordered-float 4.0.0 has been released.