[Issue 1977] Relax warnings for implicit narrowing conversions caused by promotions

[d-bugmail at puremagic.com]

http://d.puremagic.com/issues/show_bug.cgi?id=1977





------- Comment #11 from andrei at metalanguage.com  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.


--