Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unconditionally bound with T: FloatCore. #138

Merged
merged 2 commits into from
Sep 3, 2023
Merged

Commits on Sep 2, 2023

  1. Unconditionally bound with T: FloatCore.

    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...
    kpreid committed Sep 2, 2023
    Configuration menu
    Copy the full SHA
    e883495 View commit details
    Browse the repository at this point in the history
  2. Configuration menu
    Copy the full SHA
    5f8c5f1 View commit details
    Browse the repository at this point in the history