OpIndex/OpIndexAssign strange order of execution

[Moritz Maxeiner]

On Sunday, 17 September 2017 at 18:52:39 UTC, SrMordred wrote:
> struct Test{ [...] }
>
> Test t;

As described in the spec [1]

> t["a"] = 100;

gets rewritten to

---
t.opIndexAssign(100, "a");
---

, while

> t["b"]["c"] = t["a"].value;

gets rewritten to

---
t.opIndex("b").opIndexAssign(t["a"].value, "c");
---

, which has to result in your observed output (left-to-right 
evaluation order):

>
> //OUTPUT:
> opIndexAssign : index : a , value : 100
> opIndex : index : b
> opIndex : index : a
> property value : 100
> opIndexAssign : index : c , value : 100
>
> //EXPECTED OUTPUT
> opIndexAssign : index : a , value : 100
> opIndex : index : a
> property value : 100
> opIndex : index : b
> opIndexAssign : index : c , value : 100
>
> Is this right?

AFAICT from the spec, yes. Your expected output does not match 
D's rewriting rules for operator overloading.

>
> I find unexpected this mix of operations on left and right side 
> of an equal operator.

Adding some more examples to the spec to show the results of the 
rewriting rules could be useful, but AFAICT it's unambiguous.

On Monday, 18 September 2017 at 13:38:48 UTC, SrMordred wrote:
> Should I report this as a bug?

Not AFAICT.

>
> I tried a C++ equivalent code and it execute in the expected 
> order.

D does not (in general) match C++ semantics.

[1] https://dlang.org/spec/operatoroverloading.html