D arithmetic problem

[Don]

Walter Bright wrote:
> Don wrote:
>> I agree, it's bug-prone.
> 
> Any two's complement arithmetic system, with types of different sizes 
> and signed-ness, is going to have quirks. It's inescapable. Back when C 
> was standardized in the 80's, there was a huge debate about whether to 
> use signed-preserving rules or value-preserving rules. After much 
> debate, it came down to pick set A of problems or set B of problems. The 
> committee picked one (value preserving) and moved on.


Really, the problem in this case isn't two's complement, but rather C's 
cavalier attitude to implicit casting.
In this case, it's possible to isolate the implicit casts which are 
bug-prone, without affecting useful behaviour at all.

Specifically, the rule would be:
* implicit widening casts of signed integral types may occur in 
arithmetic operations, bitwise logical operations, and function calls.
* implicit widening casts of signed types  may occur in arithmetic 
operations and function calls.  It does NOT occur in bitwise logical 
operations.



> http://books.google.com/books?id=yxLISD0TAbEC&pg=PA35&lpg=PA35&dq=signed+preserving+versus+value+preserving+integral+promotion+rules&source=bl&ots=tCRBjyS4jC&sig=VCVgyAr9u0ItJbcZ5r-fLnxGmX4&hl=en&ei=riMmSufaCafcswO4vbWUBg&sa=X&oi=book_result&ct=result&resnum=9 
> 
> 
> 
>> Ideally, we'd disallow implicit widening casts for signed types in 
>> logical operations. But can that be done without creating too many 
>> language quirks?
> 
> 
> The problem with changing the rules is that the value preserving rules 
> are now deeply ingrained into how C (and C++) code is written. Changing 
> them would mean that translating complex code from C to D may produce 
> silent changes in behavior. I believe this would be very bad for D 
> because it means people would not be able to translate such code to D.

No, (in contrast to the original poster) my proposed rule change would 
just make it an error. There'd be nothing silent.

> 
> (After all, it's one thing to translate, say, an encryption program from 
> C to D. It's quite another thing to understand it well enough to be able 
> to debug it, or even verify that it is working correctly.)