[Issue 1977] integral arithmetic operation only on int?

[Don]

d-bugmail at puremagic.com wrote:
> http://d.puremagic.com/issues/show_bug.cgi?id=1977
> 
> 
> schveiguy at yahoo.com changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|RESOLVED                    |REOPENED
>          Resolution|INVALID                     |
> 
> 
> 
> 
> ------- Comment #5 from schveiguy at yahoo.com  2008-11-22 08:44 -------
> (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;
> }
> 
>> 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.

Personally I think having to insert a cast makes the code more 
error-prone. The cure is worse than the disease.

Consider also that with the original code, the compiler could install 
debug-time asserts on any such narrowing conversion. Once you insert a 
cast, that's impossible, since the language doesn't distinguish between 
(a) 'I know that is OK' casts, (b) 'I want to pretend that this is a 
different type' casts, and (c) 'I want you to change this into another 
type' casts.

Compiler checks should only be inserted for case (a) and (c).