Bug 15355 – unstable operator overloading with comma expression

Test case: struct S { int x; int y; void opIndexAssign(int v, int n) { x = v; } ref int opIndex(int n) { return y; } } void main() { S s1; s1[0] = 1; assert(s1.x == 1); S s2; (1, s2[0]) = 1; assert(s2.y == 1); // shouldn't be s2.x == 1 ? }

This might be surprising behaviour; but I think that it fits with what the comma operator does. (a, b) gets evaluated as do a, discard, do b and return. So, in this case: (1, s2[0]) = 1 Evaluate 1 and discard just does nothing. Evaluate s2[0] and return gives us a ref to s2.y. Only then does the = 1 take effect, so we end up with (ref to s2.y) = 1. So I don't think that there is actually a problem with the operator overloading in this case. As for whether or how this quirk should be fixed, I'm afraid that I can't really say.

I think it would be more appropriate if the compiler raised an ambiguity error, because the behavior is tricky and can lead to hard to track bugs. If the opIndexAssign is defined, than opIndex that returns a reference should be disallowed, or at least opIndex that returns a mutable (assignable) reference should be.

The comma operator should be killed with extreme prejudice.

The comma operator is not supported anymore in the frontend. The code now yields: test.d(24): Error: using the result of a comma expression is not allowed