More magical AA semantics

[monarch_dodra]

On Friday, 11 January 2013 at 13:27:46 UTC, deadalnix wrote:
> On Friday, 11 January 2013 at 11:14:27 UTC, monarch_dodra wrote:
>> In particular, if you define an opIndexAssign, then the RHS 
>> *has* to be evaluated first (from a "visual" point of view, 
>> since LHS is pretty much "this").
>>
>> //----
>> a[0] = a[0]
>> //----
>> Becomes
>> //----
>> a.opIndexAssign(a[0], 0);
>> //----
>>
>
> It is probably not gonna change at this point, but 
> opIndexAssign seems wrong here, not the LTR evaluation.

I find that with LTR, you end up with a value (T.init), that you 
never actually put into your array. IMO, that means something 
went wrong somewhere. This is particularly relevant with "++a[0]".

I was wondering: if AA's are "library types", as we have been 
claiming they are, then *how* does
//----
a[0] = a[0];
//----

Even work? The way I see it, there is 1 of 2 possible 
implementations:

==== 1 ====
Simple "ref T opIndex(size_t);" implementation: This does not 
allow distinguishing read from write, so would crash on *any* 
call to an empty field.

==== 2 ====
With opIndexAssign. But if we *did* have opIndexAssign, then we 
wouldn't have these problems, and the code such as "++a[0];" 
would correctly throw.

So what gives? My guess is that the compiler only has opIndex, 
but cheats to know if it is a write:
//----
immutable(int)[int] a;
a[0] = 5;
//----
Error: a[0] isn't mutable
//----

That's a tell-tale sign the compiler is cheating on us. What's 
more, if AA used opIndexAssign, this assignment would actually 
work.