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.

Denis Shelomovskij:

> IMHO, D should not have `a[]++` operator.

I see, and sorry.
(Those percentage comments are relative to tests done on large arrays, so they are silly.)

Bye,
bearophile

2011/12/24 Mr. Anonymous <mailnew4ster@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.

On 12/24/2011 06:18 PM, Andrew Wiley wrote:
> 2011/12/24 Mr. Anonymous<mailnew4ster@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);
}

On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehr <timon.gehr@gmx.ch> wrote:
> On 12/24/2011 06:18 PM, Andrew Wiley wrote:
>>
>> 2011/12/24 Mr. Anonymous<mailnew4ster@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);

On 12/24/2011 07:00 PM, Andrew Wiley wrote:
> On Sat, Dec 24, 2011 at 9:50 AM, Timon Gehr<timon.gehr@gmx.ch>  wrote:
>> On 12/24/2011 06:18 PM, Andrew Wiley wrote:
>>>
>>> 2011/12/24 Mr. Anonymous<mailnew4ster@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.

On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehr <timon.gehr@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@gmx.ch>  wrote:
>>>
>>> On 12/24/2011 06:18 PM, Andrew Wiley wrote:
>>>
>>>>
>>>> 2011/12/24 Mr. Anonymous<mailnew4ster@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.

On 24.12.2011 21:22, Andrew Wiley wrote:
> On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehr<timon.gehr@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@gmx.ch>    wrote:
>>>>
>>>> On 12/24/2011 06:18 PM, Andrew Wiley wrote:
>>>>
>>>>>
>>>>> 2011/12/24 Mr. Anonymous<mailnew4ster@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.

On 12/24/2011 08:22 PM, Andrew Wiley wrote:
> On Sat, Dec 24, 2011 at 1:08 PM, Timon Gehr<timon.gehr@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@gmx.ch>    wrote:
>>>>
>>>> On 12/24/2011 06:18 PM, Andrew Wiley wrote:
>>>>
>>>>>
>>>>> 2011/12/24 Mr. Anonymous<mailnew4ster@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.

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@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@gmx.ch> wrote:
>>>>>
>>>>> On 12/24/2011 06:18 PM, Andrew Wiley wrote:
>>>>>
>>>>>>
>>>>>> 2011/12/24 Mr. Anonymous<mailnew4ster@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.