Integer overflow and underflow semantics?

[via Digitalmars-d]

On Tuesday, 22 July 2014 at 21:06:09 UTC, Artur Skawina via 
Digitalmars-d wrote:
> D is defined as it is, with wrapping two's complement integer 
> arithmetic
> and defined integer sizes.

Integer promotion is locked to 32 bits. That is a mistake. Why 
wrap everything below 32bit at 32 on a 64 bit ALU? That's 
inconvinient and will lead to undetected bugs.

I also think it is a mistake to lock to C rules, which were 
defined when multiply often were done in software. In most modern 
ALUs a N bit multiply yields a 2*N bit result. Why discard the 
high word?

With forced wrapping/masking (a*b)>>32 is turned into 
((a*b)&0xffffffff)>>32 which is zero, so you have to cast 'a' to 
64 bit before the multiply, then downcast the result to 32 bit.

> My point is that the language must be consistent; adding special
> cases would create a language in which one expression yields 
> several
> different results, depending on evaluation context.

I understand this point, but I think code that would yield such 
errors most lkely is buggy or underspecified.

Ola.