Is it safe to call `NotNan::new_unchecked` with a non-float type? about rust-ordered-float

[mbrubeck]

Should such a construction be considered a sound usage of NotNan::new_unchecked?

Yes, this is sound because it cannot violate any invariants of the unsafe code in this crate. All of the unsafe blocks are in methods that apply only to types that implement Float.

If not, is there a reason not to add a T: Float bound to statically prohibit it?

There‘s no soundness reason to add such a bound. There‘s no real reason not to add the bound either; it just doesn‘t have any effect except on trivial code that does nothing with the constructed value.

[kpreid]

Thanks for the answer. Context on why I asked which may be interesting:

I have a need to construct NotNan<f32> in const values, and for that purpose I've defined a macro notnan! which can only construct valid NotNans by virtue of only syntactically accepting literals; the simplest possible macro_rules implementation accepts any literal and can therefore produce non-numeric NotNans, and I was wondering whether that was a soundness issue or harmless. Of course, it's arguably more user-friendly and robust against future language changes to reject them anyway.

At some point I may get around to preparing that macro as a PR for this crate. (Of course, future expansions of const evaluation in Rust may make NotNan::new(1.234).unwrap() possible to write in const context, thus making it of less value, but the macro has the arguable advantage of making it statically impossible to cause a panic.)