symmetric signed types

[Walter Bright]

On 1/23/2014 4:50 PM, bearophile wrote:
> Walter Bright:
>
>> The huge advantage of the C rules is they are very widely known, used, and
>> understood.
>
> And following them allows me to translate intricate C code to D with less
> headaches.
>
> Still, Go has adopted a different strategy...

I know.

1. Go determines the type of (e1 op e2) as the type of the first operand.

   http://golang.org/ref/spec#Arithmetic_operators

I consider this not only surprising (as we expect + to be commutative) but can 
lead to unexpected truncation, as in (byte = byte + int32). It'll also lead to 
unexpected signed/unsigned bugs when converting C code.


2. Go also requires casts in order to assign one integral type to another:

   http://golang.org/ref/spec#Assignability

I suspect that leads to a lot of casts, and such makes for hard-to-find bugs 
when code is refactored. If Go ever gets generics, this effect will get worse.



The Go rules are definitely simpler than the C rules, but I don't see otherwise 
an improvement in reducing unintended behavior.

D, on the other hand, uses C rules with implicit casting as long as value range 
propagation says truncation will not result. The rules are more complex, but 
work out surprisingly naturally and I believe are a real advance in reducing 
unintended behavior. Note that even Dominikus' "mistake" is not one that 
resulted in unexpected truncation.