Optimize Option<f64> and friends with nanboxing

[Yoric]

Once #5977 has landed, this will open up a few possible optimizations for simple enums.

One such optimization would be Option<f64> (and friends). For the moment, size_of<f64>() == 8 while size_of<Option<f64>>() == 16, but I believe that we could get it down to 8 by using nanboxing.

The idea of nanboxing is simple. In a 64-bits float, IEEE-754 actually specifies 2^52 - 1 different ways of representing NaN. Actual CPUs only use a single, which gives us 2^52 - 2 possible values that we could pick as representations for None. SpiderMonkey (and LuaJIT, and others) already uses this trick to hide dynamic type information in 64-bit values. I believe that this would work nicely in Rust, too.

[rphmeier]

See also rust-lang/rfcs#1230.

[hanna-kruppe]

It's currently legal (as in, nothing says otherwise and thus people rightly assume it's legal) to transmute arbitrary u64 values to f64. This proposal would probably require adding "a float NaN value other than the one with bit pattern [...]" to the list of invalid values in primitive types.

[jonas-schievink]

What if I want to use NaN tagging in my application? Is that just not gonna happen?

[oli-obk]

Similar to NonZero for integrals, there could be NotNan as a wrapper for floats.

This issue should probably go to the rfc repository.

[ranma42]

NotNat might also be used as a hint for (some) LLVM fast math optimisations

[Aatch]

I agree with @oli-obk on both points. Explicit opt-in is probably best here as NaN is a valid "value" for floats. A RFC for adding NonNan (or whatever) would be good to see.

[Mark-Simulacrum]

Closing in favor of an RFC.