Bug 9430 – short and byte implicitly cast to integer with binary arithmetic ops

This fails to compile with the (equivalent) errors shown below: void main() { byte[3] val = [1, 2, 3]; byte[3] res2; res[0] = val[1]+val[2]; // Error A res[0] = val[1]-val[2]; // Error A res[0] = val[1]/val[2]; // Error A byte a1 = 1, a2 = 2; byte result = a1+a2; // Error B assert(result == 4); result = a1; result += a2; // OK res[0] = val[1]; res[0] += val[2]; // OK res[0] = val[1]; res[0] -= val[2]; // OK res[0] = val[1]; res[0] *= val[2]; // OK res[0] = val[1]; res[0] /= val[2]; // OK } Error A: cannot implicitly convert expression (cast(int)val[1UL] + cast(int)val[2UL] ) of type int to byte. Error B: cannot implicitly convert expression (cast(int)a1 + cast(int)a2 ) of type int to byte. Same is true for short[] arrays. It is true for +, -, *, / NOTE: It is not the case for +=, -=, *= and /=. These work with byte and short

additional info: Compiler: DMD 2.061 x86_64 Linux OS: Fedora 18 x86_64 Binary: elf64-x86-64

This is expected behavior. It's the same as C/C++ (and probably Java and C#, though I don't remember for sure). Arithmetic operations on integral types result in the largest integral type in the expression or in int if the integral types are smaller than int. And as D requires explicit casts for narrowing conversions (unlike C/C++), a cast is then required to assign to a variable of an integral type smaller than int. So, C/C++ do exactly the same thing as D is doing here, but they allow the implicit cast back to the smaller type, whereas D does not. Unlike C/C++, D _does_ do range propagation such that if it can determine for certain that the result would fit in the smaller type, the cast isn't required, but that generally requires that integer literals be involved. +=, -=, etc. work because there's no way to do the cast. If you had a = a + b; then you could do a = cast(byte)(a + b); but there's no place to put the cast in a += b; And you're effectively asking for the cast, because the result is being reassigned to a. Whereas with a = a + b; the expression on the right hand side (and its type) are evaluated before the assignment takes place, so the fact that you're assigning the result of the expression to a has no effect on how its evaluated or what its type is. While this behavior might be a bit annoying, it follows from the fact that D requires explicit casts for narrowing conversions, and it generally prevents bugs.

Thanks very much for the explanation, I mistakenly thought D was supposed to perform the implicit cast as well. I'm glad this is intentional, I much prefer the explicit cast that D requires.