Bug 17417 – Deprecate signed integer promotions in bitwise operations

Signed integers - byte and short - are promoted to int in bitwise operations which doesn't make much sense and is bug prone. Also true for promotion from int to long in binary bitwise operations.

There is a good reason to do the promotion. The generated machine-code is more efficient in many cases. Types smaller the uint should only be used for storage, not for operations :)

Promotion in bitwise operators makes better sense for unsigned integers, but doesn't make much sense for signed integers, bitwise operators are supposed to act on bit arrays, which signed integers are not. After deprecation the compiler should give an error for signed integer promotions in bitwise operators.

(In reply to anonymous4 from comment #2) > Promotion in bitwise operators makes better sense for unsigned integers, but > doesn't make much sense for signed integers, bitwise operators are supposed > to act on bit arrays, which signed integers are not. After deprecation the > compiler should give an error for signed integer promotions in bitwise > operators. There is precedent for for bitwise operations on singed integers as well, such as right/left shifts. To save division cost

I think it's usually used with int, in which case there will be no promotion. Another thing I can think of is cast(ubyte)(short>>8) which would be a bit more difficult to check that sign extension doesn't affect the result if we would want to allow it.

This is core behavior that we don't plan to change. Value Range Propagation is the way to avoid casts back and forth. Feel free to submit issues related to it, thanks.

The issue is not about VRP. Integer promotions don't require casts and happen without casts (basically inadvertently). Example: if we have two 16-bit values and want to combine them into a 32-bit value: uint v=(s1<<16)|s2; VRP has nothing to do here.

VRP can't do anything here because promotion works according to spec.

Whether or not VRP may help the situation, we won't change the operators. Please do not reopen, thanks.