Shifts not implemented on floats, f32, f64

[bjackson]

Are there plans for these to be implemented, or are they intentionally left out? I noticed in the development core wiki that more bitwise goodies were available for ints, but binary operations on floats were left out.

[Aatch]

Floating point numbers have no obvious semantics with regards to shifting, compared to integers.

Example, 45i << 2 == 180, is fairly well understood. What does this expression produce: 65.494 << 2? To match the mathmatical result for ints, it would need to be 261.976, but if it's a bit shift, then it's (according to a quick program I wrote) 0.000000 for a f32 and -369098.750000 for f64.

More importantly, there is no basic operation for floating point shifts so it would have to be implemented in software. Rust is a systems language, so hidden costs are considered bad and shifting is generally considered to be a speedy operation. having 1f << 5 take a hundred more cycles than 1 << 5 is pretty hidden to me.

Lastly, what use would it be? Bit shifting is normally done for the encoding of data at a bit level, but floating point numbers are bit-level encoding. You are essentially asking if we are planning to implement a way to corrupt floating point numbers at a language level.

---

Not a bug. Closing.

[catamorphism]

@Aatch , that's not quite true; for example, LLVM has a floating-point shift instruction: http://llvm.org/docs/doxygen/html/namespacellvm_1_1X86ISD.html

My understanding is that typically, low-level compiler optimizations would turn other floating-point operations onto shifts (operating on the bit-level representation of floats so as to preserve semantics; floats aren't magic, you can manipulate their representations just as with ints), but this isn't an area I'm particularly familiar with. On the other hand, I don't imagine rustc would ever do these optimizations, since LLVM can do them perfectly well. @graydon , can you confirm/deny that this bug should stay closed?