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.
