A opIndexUnary quiz

[Peter Summerland]

On Thursday, 3 January 2013 at 07:03:23 UTC, monarch_dodra wrote:
> On Thursday, 3 January 2013 at 00:08:12 UTC, Peter Summerland 
> wrote:
>> On Wednesday, 2 January 2013 at 03:52:21 UTC, bearophile wrote:
>>> Era Scarecrow:
>>>
>>>> Well I see that you have opIndexUnary twice; According to 
>>>> the manual you wouldn't need as it would rewrite the code so 
>>>> you only need it once;
>>>
>>> And as you have seen if you remove the useles opIndexRight 
>>> the program keeps compiling with no errors and keeps 
>>> asserting at run-time:
>>>
>>>
>>>
>>> struct Foo {
>>>   int x;
>>>   alias this = x;
>>> }
>>>
>>> class Bar {
>>>   Foo[] data;
>>>
>>>   this() {
>>>       data.length = 10;
>>>   }
>>>
>>>   Foo opIndex(uint i) {
>>>       return data[i];
>>>   }
>>>
>>>   void opIndexUnary(string op)(uint i) if (op == "++") {
>>>       data[i]++;
>>>   }
>>> }
>>>
>>> void main() {
>>>   auto barfoo = new Bar;
>>>   ++barfoo[3];
>>>   assert(barfoo.data[3] == 1);
>>>   barfoo[3]++;
>>>   assert(barfoo.data[3] == 2);
>>> }
>>>
>>>
>>> Bye,
>>> bearophile
>>
>> I am really just guessing, but it appears that whatever the 
>> post increment op gets rewritten as takes either a reference 
>> to or a copy of what is being incremented and it involves 
>> opIndex, not opIndexUnary as suggested by TDPL p. 378 and p. 
>> 369.

Thanks for responding.

On rereading, maybe TDPL is just suggesting that the rewrite for 
a[i]++ should be handled exactly the same as foo++, where foo and 
a[i] are Foos. I.e., if the result of a[i]++ is not used, rewrite 
it as ++a[i]. That apparently is not happening, as reported in 
bug 5044. But if a[i]++ is used, then apply

(ref x){auto t=x; ++x; return t;} to (a[i])

which causes the function to be applied to a copy of a[i], 
resulting in the nop effect of a[i]++ (unless a[i] returns a ref, 
and we don't want that). So IMHO using the the general rewrite at 
p369 for indexed items is incorrect. And base don my probing, I 
am guessing that the general rewrite is indeed applied to a[i]++.

Would it be possible to have the compiler call 
opIndexUnary!"<op>"(b1, ...bk) where <op> could be, say, "post++" 
and "post--" in addition to "++" and "--", when appropriate? 
Seems like a simple solution.

>
> That's a (old) bug. If opIndexUnary is present, then that 
> should be called. However, currently, the compiler doesn't 
> "see" it when it sees "a[i]++".
>
> http://d.puremagic.com/issues/show_bug.cgi?id=5044
>
> "++a[i]" works correctly (AFAIK). If you want to test opUnary, 
> DO NOT toy around with the post increment index version. Just 
> stick to simple unary:
> "++a" and "a++"

Sorry for the messy example, but I did not mean to test opUnary. 
In the code, I just wanted to see if the rewrite of a[i]++ was 
calling it (which it is - in version A and version B).


>
>> If opIndex is changed to return ref Foo, everything works. (I 
>> had change alias this = x to alias x this - 2.60 64 bit). Here 
>> is code that shows when opIndexUnary and opIndex is called and 
>> when the assertion fails for version(B) - with ref and 
>> version(A) without ref.
>
> As soon as opIndex returns a ref, then *nothing* of 
> opIndexSomething becomes necessary (heck, it becomes "counter 
> necessary"). Same thing for front. If front returns by ref, 
> then you don't need the "front(T t)" variant.
>
> I don't have TDPL under my eyes right now, but I remember it 
> explicitly stating that these functions where specifically 
> meant to emulate access primitives, for functions that can't 
> ref access to its primitives. In particular, for things like 
> array bool.