Reading about D: few questions

[Mr. Anonymous]

On 24.12.2011 19:18, Andrew Wiley wrote:
> 2011/12/24 Mr. Anonymous<mailnew4ster at gmail.com>:
>> On 24.12.2011 19:01, Denis Shelomovskij wrote:
>>>
>>> 23.12.2011 22:51, bearophile пишет:
>>>>>
>>>>> ++a[] works, but a[]++ doesn't.
>>>>
>>>> Already known compiler bug.
>>>
>>>
>>> Is it a joke? Array expression in D are for performance reasons to
>>> generate x2-x100 faster code without any compiler optimisations. Link to
>>> one of these epic comments (even x100 more epic because of '%' use
>>> instead of 'x###'):
>>>
>>> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/arraybyte.d#L1127
>>>
>>>
>>> But `a[]++` should store a copy of `a`, increment elements and return
>>> stored copy. It is hidden GC allocation. We already have a silent
>>> allocation in closures, but here a _really large_ peace of data can be
>>> allocated. Yes, this allocation sometimes can be optimized out but not
>>> always.
>>>
>>> IMHO, D should not have `a[]++` operator.
>>
>>
>> Why should it store a copy? o_O
>> I also don't see any allocations in the code on the URL above.
>
> int a_orig = a++;
> int[] arr_orig = arr[]++;
>
> If ++ is going to be applied to an array, it needs to have the same
> meaning as it does elsewhere. After this operation, arr_orig and arr
> must refer to different arrays for that to be true.

Actually, when I think of it:

int a_orig = a++;
int[] arr_orig = arr[]++;

Should be read as:

int a_orig = a;
++a;
int[] arr_orig = arr[];
++arr[];

(If I'm not mistaken, it was written in the TDPL book)

Which means no copy of arr is made, and both arrays (which reference to 
the same block) are affected.