RFC: Removing `float'

[auroranockert]

float and f64 are not currently the same type in Rust.

We discussed it on IRC and couldn't think of a good reason to have them separated, and some reasons to have only one type (with a possible typedef to keep both names).

The pros of mergeing the types include

• Less casting
• Makes the precision of float explicit

[brendanzab]

I was talking to @brson a while back on IRC about this. I think he had a reason to keep it, but I can't remember what it was.

All I know is that core::float has pretty much turned into one big cast for the stuff defined in core::f64. Seems a tad repetitive.

[emberian]

I think float is useful for literals. 1.0f is much prettier than 1.0f64. So, at the very least, keeping that literal syntax around would be nice.

[Kimundi]

As far as I know there reason for a separate float is that it represents the fastest floating point type for a platform.

So, for example on a machine that has fast native f32 but slow software f64 a float would be an f32 internally. Of course at the moment the library just hard codes all 'float' operations to casted f64s, but that's an separate issue.

The reason it's a separate type and not a typedef is the same as for (u)ints: Code would break on other platforms if you rely on it being the same type with just another name.

[thestinger]

So why are we using f64 for float on x86/x86_64? The legacy x87 floating point support is neither 32-bit or 64-bit - they're emulated on top of 80-bit registers. SSE supports both floats and doubles natively - there's no reason a double would be faster since it uses 2x the cache space and SSE operations can do 4 floats at a time but only 2 doubles.

Is there really an architecture where a double is faster?

[auroranockert]

@Kimundi That doesn't make any sense though, as changing floating-point format under the feet of a program will more than likely break it in much more complex ways than the size_t-alikes int/uint.

OpenGL ES for example does this, and gets http://youilabs.com/blog/mobile-gpu-floating-point-accuracy-variances/ as a result. (Note that the conclusion in that blog post is slightly wrong though)

[bstrie]

@cmr I believe that writing simply 1.0 will already infer the type of float that you want, without requiring a suffix.

[cscott]

in theory "float" should be f80 on x86, as that's fastest...

[thestinger]

@cscott: only with the legacy x87 support though

[emberian]

ML thread: http://article.gmane.org/gmane.comp.lang.rust.devel/4561/match=removing+float

[catamorphism]

Nominating for milestone 1, well-defined

[catamorphism]

Accepted for well-defined

[auroranockert]

@catamorphism: Does this mean we decided to remove float as a different type from f64? Should I write a patch to do it?

[thestinger]

I think there's consensus that it's useless as implemented right now. If it's supposed to be the fastest type for the platform, it should be f32 on most platforms. I don't think a use case for highest precision possible with a native floating point type has been presented because varying results across platforms is strange.

[lilyball]

I don't agree with @thestinger that highest precision possible with a native floating point type is bad. But I think removing float makes just as much sense as trying to nail down a predictable behavior for it.

Once removed, the question then becomes what type 1.0 acquires if it's not otherwise constrained. The three options are: f32, f64, or throwing an error. The latter makes sense if you want to leave open the door for arbitrary-precision floating point as the default later, although I believe that would be too much of a hidden performance hit to ever do. My vote is for defaulting to f64.