On 05/25/2015 10:02 PM, Daniel Murphy wrote:
"Timon Gehr" wrote in message news:mjvtqm$17d8$1...@digitalmars.com...
A related issue is that the rewrites documented at
http://dlang.org/operatoroverloading.html don't all preserve the order
of subexpressions. However, ideally, the order of evaluation would be
preserved.
As operator overloading is defined in terms of lowering to function
calls, I think it's reasonable to decide the order of evaluation after
the lowering. This will still be consistent across compilers and
platforms.
But almost entirely arbitrary.
Preserving the original order would require added complexity
that I don't think is warranted.
The compiler would just need to introduce some temporary variables for
the two lowerings. Why wouldn't this be warranted to make overloaded
operators consistent with built-in ones? If anything, I think it is
desirable to have opBinary(B) on type A and opBinaryRight(A) on type B
interchangeable.
What complexity are you worried about?
