Bug 3241 – Limitations of array operations with parenthesis

Example code: void main() { int[8] a, b, c, d; //a[] += (a[] + 2*c[] - 3*b[]); // ok a[] += 4*(a[] + 2*c[] - 3*b[]); // not ok writefln(a); } commented line doesn't compile, giving error message: v.d(7): Error: incompatible types for ((4) * (a[] + c[] * 2 - b[] * 3)): 'int' and 'int[]' v.d(7): Error: 'a[] + c[] * 2 - b[] * 3' is not of arithmetic type, it is a int[] the "4*" part can be manually propageted into the parenthesis (4*a[] + 4*2*c[] - 4*3*b[]), and this works, but why compiler can't do this? There is even strange problem, for example with + operator: a[] += 4+(a[] + 2*c[] - 3*b[]); this gives also: v.d(9): Error: incompatible types for ((4) + (a[] + c[] * 2 - b[] * 3)): 'int' and 'int[]' but just removing parenthesis: a[] += 4+a[] + 2*c[] - 3*b[]; produces correct code. This problem is probably because array operation generator doesn't look into expressions in parenthesis, just check it types. So a[] += 4+(a[] + 2*c[] - 3*b[]); would be equivalent (if supported) to creating temporary: int[8] temp = a[] + 2*c[] - 3*b[]; a[] += 4+temp[]; this would be suboptimal, because there will be double loop used in generated code, and excess coping. AFAIK, BLAZE vector code generator allow such operations. Because of this we can't also use pure mathematical function on arrays, a[] += sin(b[])*d[] + e[]; It would be awsome to have something like that. (given that sin is pure function). BTW. I also noticed that spec doesn't say anything about custom types with operators overloaded. It probably just calls given operators in inner loop, but this operator probably creats own temporaries. Is there any optimalisations planed like allocation of this variables moved out of loop, or using opXAssign operators if compiler can optimalise it, somehow. like: a[] += b[]*d[]*e[] + 5; => // code gen T t; // T is struct or class, with some operators overloaded foreach (i, ref v; a) { t = b[i]*d[i]; t *= e[i]; t += 5; a[i] += t; } I know compiler doesn't know which operator opMul or opMulAssing is more efficient, but given that it is mandatory to have a *= b, operate like a = a * b;, it doesn't metter. This can be very powerfull substitute for "expression templates" from C++. (i know they are kind of voodoo and very powerfull, but we can mayby use only part of it). It is used for example in Blitz++ library. Actually we can already emulate them using our template magic, and is quite flexible. Custom rules for array operations generator can be also usefull, but don't know how we would specify them. Mayby we should wait for D "macros" which will just allow us to investigate part of expression? This would make building custom AST using templates not needed.

Interesting. In 2.039+ this examples works and produces correct results.

Fixed DMD1.051 and 2.036.