Well, fair enough. To be honest, I think the potential for domain optimisations actually provides the weakest support for this feature; I doubt it's going to be useful until paired with some sort of attribute for code blocks (maybe unsafe blocks only?) like #[float_optim(assoc,distrib,cancel)], which would control what floating-point optimisations are allowed within that block.
And I was indeed the least sure about how useful Finite would be. I think I'm going to remove it.
The matter's hardly settled; the discussion may still turn out in favour of making NonZero unstable indefinitely, or until some form of 'closed traits' (not implementable by external crates) arrives. I think I'll propose something similar for my Ieee754 trait.
On the other hand, I also thought about creating projective floating-point types (which would identify +∞ with −∞). Doing this with generics would raise the question of whether a non-NaN projective float should be...
Projective<NaNaN<f64>>NaNaN<Projective<f64>>- both, with
Fromconverting between the two forms - neither, a separate wrapper:
ProjNaNaN<f64>
It kind of does, but UniqNaN has some semantics for which it is unclear if they will fit for Option<NaNaN> in every case; compare the table in your own post in the discussion about lifting operations for Option<_>, which you could basically frame as raising the question whether None represents a lack of a value, or a value that is unknown. Plus, it's probably going to be easier for the optimiser to take advantage of a 'ready-made' type when eliding and shuffling NaN canonicalisation operations. (I talk about this in the 'Alternatives' section.)
I mention this in the 'Unresolved questions' section; I think this is an issue that could be addressed during the course of the RFC proper. I assume you're in favour of the 'panicking' option?
I agree about checked_; these methods should be definitely provided.
That gave me the idea that perhaps type inference could be tweaked to allow fraction literals (1.234) to be of these types...