[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 #7 from andrei at metalanguage.com  2008-11-22 10:59 -------
(In reply to comment #5)
> (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.
> 
> Why is this also flagged (no overflow possible):
> 
> short f(byte i) {
>   byte t = 1;
>   short o = t - i;
>   return o;
> }

This should go through no problem indeed, I hadn't seen your first reply when I
replied.

> > The community has insisted for a long time to tighten integral operations, and
> > now that it's happening, the tightening is reported as a bug :o).
> 
> But it's pretty inconsistent.  If I add two random ints together, I will get an
> overflow in 25% of cases, why is that not flagged?
> 
> I think the restriction is too tight.  People expect to do math on homogeneous
> types without having to cast the result, as they do with ints.  And I'll say I
> was not one of the people asking for this 'feature'.  I'm not sure where that
> came from.

In general, we want to go with the simple rule is to have an operation return
the tightest type that won't engender overflow (which precludes making 8- and
16-bit values as closed sets for addition). The exception to that is int, which
for a combination of practical reasons, "stays" int even if it could overflow,
and also long, which cannot go any larger. Anecdotal evidence suggests that
unintended overflows can be more annoying than having to insert the occasional
cast.

We could relax this rule by having the compiler statically tracking possible
ranges of values.

The random ints argument does not quite hold because one seldom adds fully
random 32-bit values. "Most integers are small."


--