`NotNan::new` can be `const`

[bentheiii]

Hello. AFAICT, there's no reason for NotNan::new to not be const. This will allow users to safely unwrap float literals in a const context.

let my_default_non_nan_float = const {NotNan::new(0.5).unwrap()};

I'd be happy to make a PR if this is approved

[mbrubeck]

Two issues:

• f64::is_nan is const since Rust 1.83, but this crate currently supports older versions. I am willing to increase the required Rust version, but I might want to wait a bit before doing this. Edit: The minimum supported Rust version is now 1.90.
• num_traits::FloatCore::is_nan is not const, so this can't be done in the existing generic impl. This might need to be a new method bounded on the PrimitiveFloat trait.

[upsuper]

f64::is_nan is const since Rust 1.83, but this crate currently supports older versions. I am willing to increase the required Rust version, but I might want to wait a bit before doing this.

Rust 1.83 was released on Nov 2024, so it's more than a year old now. Should we consider increasing the required version for this again?

num_traits::FloatCore::is_nan is not const, so this can't be done in the existing generic impl.

This is probably unsolvable for now, because Rust doesn't currently even allow associated functions to be declared const on trait.

This might need to be a new method bounded on the PrimitiveFloat trait.

But I'd also support a new method, like new_const, and it could just unwrap inside rather than returning Result.

[upsuper]

Actually, because trait can not have associated const function, adding a new method in PrimitiveFloat is not going to work either. It would have to declare them separately for each primitive float type like

impl NotNan<f32> {
    pub const fn new_const(val: f32) -> Self {
        assert!(!val.is_nan());
        NotNan(val)
    }
}

impl NotNan<f64> {
    pub const fn new_const(val: f64) -> Self {
        assert!(!val.is_nan());
        NotNan(val)
    }
}

But this has another problem: you can't write NotNan::new_const(0.5), or even NotNan::new_const(0.5f32) anymore, because they are now two separate functions, so the type parameter needs to be explicit, i.e. NotNan::<f32>::new_const(0.5) (and, no, this can't be inferred either, so const X: NotNan<f32> = NotNan::new_const(0.5) doesn't work as well).