Reading about D: few questions

[Timon Gehr]

On 12/24/2011 08:22 PM, Andrew Wiley wrote:
> On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehr<timon.gehr at gmx.ch>  wrote:
>> On 12/24/2011 07:00 PM, Andrew Wiley wrote:
>>>
>>> On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehr<timon.gehr at gmx.ch>    wrote:
>>>>
>>>> On 12/24/2011 06:18 PM, 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.
>>>>
>>>>
>>>>
>>>> Not necessarily.
>>>>
>>>> class D{
>>>>     int payload;
>>>>     D opUnary(string op:"++")(){payload++; return this;}
>>>> }
>>>>
>>>> void main() {
>>>>     D d = new D;
>>>>     assert(d.payload == 0);
>>>>     assert(d++.payload == 1);
>>>> }
>>>
>>>
>>> That doesn't match integer semantics:
>>> int a = 0;
>>> assert(a++ == 0);
>>> assert(a == 1);
>>
>>
>> Yes, that was my point.
>>
>
> Then I'm not understanding what you're trying to prove.
> I'm saying that if we implement a postfix ++ operator for arrays,
> keeping the language consistent would require it to make a copy if the
> user stores a copy of the original array.

And I said: "not necessarily"

That is because reference types have had semantics that go well with not 
making a copy all along, so there is no danger of making things more 
inconsistent.

> I guess it could be argued
> that since arrays have hybrid value/reference semantics, no copy
> should be made and the original should change.
>
> Actually, looking at it from that angle, a[]++ is fundamentally
> ambiguous because it could have value semantics or reference
> semantics, so I would argue that we shouldn't have it for that reason.
> '++a' and 'a += 1' do not have such ambiguities.

I don't think a[]++ should necessarily be there either.