http://d.puremagic.com/issues/show_bug.cgi?id=1977
------- Comment #11 from [EMAIL PROTECTED] 2008-11-22 12:51 ------- (In reply to comment #9) > (In reply to comment #8) > > The plan is to have sensible bitwise operations preserve the size of their > > operands. Only arithmetic and shift will "spill" into larger types. > > > > I hope you mean only *left* shift will spill into a larger type. Correct. So let's recap a possible set of rules: (a) Operations will yield the statically tightest type possible, but never smaller than the largest of the two operands. (b) However, (a) will not cause automatic promotion from 32-bit to 64-bit, i.e., unless at least one operand is 64-bit, the result will never be 64-bit. (c) (Not yet implemented) If one operand's value is statically-known, further tightening without a cast is possible, e.g.: uint a = ...; byte b = a & 1; // pass, no cast needed (d) (Not yet implemented, open-ended) Even if operand values are not statically known, their possible range is computed statically in a flow-insensitive manner and used for validation, e.g.: uint a = 4; if (condition) a = 200; // a is not in range [4, 200] ubyte x = a & 200; // pass ==== The "but never smaller than the largest of the two operands" is meant to avoid surprises of the following sort: uint a = ...; auto b = a & 1; // how do you mean b is ubyte?!? However, notice that due to (c), explicitly asking for a byte does work. --