Reading about D: few questions

[Andrew Wiley]

On Sat, Dec 24, 2011 at 1:45 PM, Timon Gehr <timon.gehr at gmx.ch> wrote:
> On 12/24/2011 08:41 PM, Mr. Anonymous wrote:
>>
>> On 24.12.2011 21:22, 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. 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.
>>
>>
>> Maybe you're right, but a[]++; alone, imo, should compile.
>
>
> +1.

You could special case this, but I'd be happy with an error that told
you to use one of the working alternatives.