[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 #8 from andrei at metalanguage.com  2008-11-22 11:04 -------
(In reply to comment #6)
> (In reply to comment #4)
> > It's not ridiculous at all.  The compiler cannot tell what values 
> > will be possibly passed to f, and the range of byte and short are 
> > sufficiently small to make overflow as frequent as it is confusing 
> > and undesirable.
> 
> I disagree:
> - Read comment 3.  How can adding (or even subtracting, multiplying or
> dividing) two numbers in the range [-128, 127] possibly produce a value outside
> the range [-32768, 32767]?

Sorry. Indeed, that is a good reason to keep the bug opened.

> - If you're using (u)byte/(u)short, it follows that you should know what you're
> doing.  Especially if you're doing it in an initialiser of something declared
> explicitly as one of these types, in which case you've shown that you know what
> you're doing.

Often, a 8/16-bit int comes from a need to minimize occupied storage in a
larger structure, to conform to some format etc. I do agree that often people
operating with such structures/in such environments do know what they're doing,
but that doesn't mean that implies they must increase their attention. Knowing
what they're doing, they'll insert a cast.

> - It happens even in the case of bitwise operations (&, |, ^, >>, >>>, but
> strangely not ~), by which overflow is impossible.  It might be sensible for
> <<, but no more.

The plan is to have sensible bitwise operations preserve the size of their
operands. Only arithmetic and shift will "spill" into larger types.


--