bit shift operators take odd types

[nikomatsakis]

It doesn't make much sense to me that in the expression x >> y (resp. x << y) both x and y have to be the same types. After all, it's not like a u32 value as 2^32 bits!

I think y should always be u8 (or perhaps uint if we want to be nice, much as we allow int in array lookups). Actually, does x >> -3 do something sensible, or is -3 just treated as a real big unsigned value?

[jckarter]

At the LLVM IR level bitshifting is undefined for negative values, or values greater than or equal to the value size. Even more reason to restrict them to a small unsigned type.

[brson]

I like uint, just for aesthetic reasons.

[graydon]

We can define negative shifts as "positive in the opposite direction" or such, don't need to be bound by LLVM here. I'd prefer to support them, but agree that we should probably accept a wide variety of types for shift-amount.

[nikomatsakis]

If we stray from LLVM it just means that "x >> y" will compile down to having some ifs and so forth. But then the common case is to shift by a constant, so perhaps that's a non-issue. I'd rather not have undefined results for bitshifts if we can help it. Ideally, something like Xu32 >> 32 would be 0, not undefined.

[jckarter]

Having the common case x >> y be safe and well-defined seems like a good idea, especially because the shift amount is so often a constant. You all could hide unsafe_shift_left/right intrinsics somewhere that map directly to the LLVM instructions.

[bzbarsky]

I just ran into this today within minutes of starting to use rust. Having to suffix all constant shifts with u32 just because I happen to be shifting a 32-bit unsigned quantity is a huge pain....

[brson]

Fixed by 99a4866. The issue about shift being undefined in some situations can be dealt with in #1877.